Alright, who wants to test busybox-power for Harmattan?

You'll need to incept the deb, or install it with AEGIS_FIXED_ORIGIN=com.nokia.maemo if you're running Open Mode*. I previously said this wouldn't be necessary, but although I did got it working that way, I learned that busybox-power will be a lot less cleaner and less user friendly if we go that route.

Busybox-power for Harmattan has two dependencies not found in busybox-power for Fremantle: aegisctl and meego-confirm-text.

• Aegisctl is used to temporarily disable the source origin check for binaries during the period between (un)installing busybox-power and a reboot**. We could do away with this dependency by reloading Harmattan's refhashlist after (un)installation (which we do ayway), but then there would be a very brief period in which /bin/busybox would be inaccessible (!). As brief as this period is, I can't guarantee that no script on the entire device will try to access /bin/busybox in that period, hence the dependency.
• Meego-confirm-text is a small (~20KiB) QML/C++ application I made to provide a maemo-confirm-text implementation for Harmattan. It is used to display the warning you'll have to agree with during the first busybox-power installation and displaying encountered issues during uninstallation, just like on Fremantle. This application might be useful for other packages or scripts as well (for displaying Licence agreements or warnings).

Please go forth and test this testing release. I've tried the most obscure (un)install situations I could think of and did not encounter any issues, so I have good faith in the current (un)install framework. Furthermore, since Harmattan ships with a pretty recent BusyBox version, little problems should arise from using busybox-power (I have yet to encounter any ). If you do find a regression however, don't hesitate to let me know!

Obligatory warning: Prepare for the worst, backup your important data. Download links:
Meego-confirm-text: https://garage.maemo.org/frs/downloa....0.1_armel.deb
Aegisctl: http://talk.maemo.org/showthread.php?t=82991
Busybox-power for Harmattan (needs to be incepted): https://garage.maemo.org/frs/downloa...tan0_armel.deb

On other news: I've integrated dpkg-divert in busybox-power for Fremantle. I was previously unaware of this nifty little utility (I don't run a Debian-based OS on my laptop), hence it was not used before. By creating a diversion for /bin/busybox, future BusyBox updates (e.g. by CSSU) won't overwrite our binary.
Unfortunately Nokia has disallowed diversions on Harmattan, so we can't use them there.

All changes made to busybox-power, as well as meego-confirm-text's source, will be pushed shortly to busybox-power's garage page.

* I have not tested busybox-power in Open Mode yet, but I can't think of any issues that would arise. Please hold off installing the deb for a while until I've tested it myself if you want verification. I'll have to read up on entering Open Mode first though .

** I do have some code ready to re-enable the check accordingly to its previous state, but I'm not sure it'll work in Open Mode and is therefore not included yet. I plan to include this feature as soon as my device gets into Open Mode. Until then, it is best to reboot your device after (un)installing busybox-power for maximum security.

Edit: heh, forgot that this topic is posted in the "Maemo 5 / Fremantle" subforum. Well, I suppose that this thread will need to be moved to "Applications" once busybox-power for Harmattan sees its final release.

Awesome. I assume that we can skip rebuilding refhashlist with Open Mode?

Edit: Didn't read the part where you didn't test it under Open Mode.
I'll go test it myself, then.

The refhashlist gets automatically resigned in postinst/prerm. Unless the signing actually fails in Open Mode (accli return a non-zero status), installation should go fine. I assume the singing will go fine, although it obviously won't have any effect in Open Mode.
If the signing would fail however, the postinst/prerm will handle it gracefully.

P.S. you could inspect the postinst/prerm file yourself, the relevant commands can be found in INSTALL() and UNINSTALL() respectively. If you, or anyone else, sees something that would not work in Open Mode, let me know. I'll try to go into Open mode myself today, so I hope to know by the end of the day whether the (un)installation in its current form works in Open Mode or not.

Update: there are two flavours of Open Mode: one with aegis neutered ("patched" Open Mode), and one without. The current busybox-power installation works on both, but is less than ideal when running patched Open Mode. I need to create a function that can reliably determine whether aegis' source origin check is enabled or not and call aegisctl accordingly. Aegisctl itself won't do for this check, it reports the check is enabled in patched Open Mode.
The function is required since it's best not to call aegisctl to modify security options in patched Open Mode; aegisctl appears to fail when you try to run it a second time without a reboot in between. Stay tuned for updates.

I would definitely wonder how exactly you'd check for that using the regular Aegis tools, as with the neutered Aegis ("Yes, we passed all checks, sire!") kernel, it does what it says on the lid - not return an -EPERM.

Perhaps check uname for the build date? IIRC there is no versioning method published for these kernels, especially that they're not flashable on-device like the N900.

I suggest that new aftermarket kernels leave a sysfs entry (/sys/kernel/security/validator/neutered, perhaps?) to let developers know which kind of device they're working with. Especially when it's an unknown ratio of Inception:Openmode users.

The only way I can think of to reliably determine aegis' true enforcement status, is by actually testing it. We only need to get an executable file under aegis' protection, backup & modify it, and test whether it can still be executed. This executable file could be a simple shell script that calls "exit 0".
The executable file and code to "test it" (and restore it afterwards) could be included in busybox-power's packaging or a separate "aegis-test-enforcement" package (which could be reused by other packages).

Unfortunately, this is by all means not a proper solution to the problem. And besides that, it only tests one aspect of aegis' security options.

This crossed my mind as well. The build date doesn't say anything about aegis being neutered or not however.
And including a list of known patched Open Mode kernels doesn't really sound sustainable as well :-/.

This would most definitely be a good solution. We need to be able to reliably differentiate patched Open Mode kernels from regular kernels missing Nokia's signature, and the (lack of) presence of a sysfs entry could do this job.

Time for some updates!

First of all, Harmattan support is done. Well, I'm not aware of any bugs at the moment to put it differently . (Un)installation works in normal mode, open mode, and patched open mode; you won't have to worry about that part at all. To view the magic, click here and here.
I've contacted MohammadAG for inclusion of busybox-power for Harmattan in his incepted-repo and got a positive response (thanks ivgalvez for the suggestion!). The sources have been sent already .
As always, debs are also available from busybox-power's garage page. Scroll all the way down to find the Harmattan builds. Don't forget to incept the deb or install it with AEGIS_FIXED_ORIGIN=com.nokia.maemo.

Do note that even though I have all faith in busybox-power for Harmattan (you don't want to know how much I've tested), it is still new and therefore has a higher chance to contain a bug.

Busybox-power for Harmattan depends on meego-confirm-text, which isn't available from Harmattan's community repositories yet. I have to make myself familiar with the current status of Harmattan's community repositories first. For the time being, you'll have to grab the deb and install it yourself. Luckily you only have to do this once .

Secondly, busybox-power for Fremantle has been updated too. It now integrates dpkg-divert in the (un)installation process, so we won't have to worry about future busybox upgrades overwriting the enhanced binary. You can grab the thumbified version of this latest update from our garage page until it's available from community-thumb.

Lastly, most applets execute faster since our latest release. We've increased the copy buffer size in BusyBox' configuration, which -I quote from Debian's changelog- "increases [the] speed of various applets dramatically". Some quick tests performed by myself confirm this. Both the N900 as well as the N9(50) have enough resources to accommodate this larger buffer.

Enjoy!

First of all thank you for your efforts,
kind of out of the way, what about creating a separate announce thread for harmattan version ? we dont want things to be mixed up as in apkenv thread
best wishes

./sifo

Thanks for the suggestion. I still have to decide what's best re: threads here. Currently I'm leaning towards a request to move this thread to the application section at TMO (and rename this thread to [N900/N9/N950] Enhanced BusyBox package" or something like that). I'll keep everyone updated regarding this topic.

+1 for idea of different topic for harmattan version.

It's not about "separatism" - it's just too much different boats, to be healthy mixed, comprehensiveness of thread get hurt in the process.

/Estel

At first I would also say so, but rethinking there will also be lot of common tasks/problems/updates/announces and so on.
Take your time iDont and do what you think is the best.