Integrate unl0kr as an osk-sdl alternative

This issue is meant for discussing how unl0kr could be integrated into pmOS as an alternative to osk-sdl. This touches upon many different tools and repositories so I hope it's fine to put it here.

A preliminary unl0kr package and changes needed to make init.sh agnostic of the unlocking program were implemented in !2687 (merged). There are several open questions though:

(1) init_functions.sh still relies on osk-sdl for retrieving its configured font path to use it with charging-sdl. The latter is disabled at the moment (see #1064 (closed)) but will probably make a return at some point. To break the dependency, maybe charging-sdl could provide its own configuration file? Alternatively, I think there was also a charging-lvgl program. Not sure if that will replace charging-sdl at some point?

(2) How are we gonna make postmarketos-mkinitfs agnostic of the unlocking program? It currently is hardwired to bundle osk-sdl and its dependencies. Could these files be provided through hooks instead (similar to how /usr/bin/unlock is provided in !2687 (merged))?

(3) How will users be able to select between osk-sdl and unl0kr when installing with pmbootstrap? Maybe the --fde switch could take the unlocking package name as an argument? We could make the default/no-argument case select osk-sdl so that the interface remains backwards compatible.

(4) Do we have to do anything to support switching between osk-sdl and unl0kr after installing?

There are probably other aspects which I haven't thought about yet so I'm really looking forward to thoughts and opinions.

CC @craftyguy @ollieparanoid

changed the description

By Johannes Marbach on 2021-11-21T12:39:35

mentioned in merge request !2687 (merged)

By Johannes Marbach on 2021-11-21T12:43:42

1. charging-sdl needs to be removed or replaced, so I would just break it if it means moving towards the goal of supporting multiple unlocker options. whoever resurrects charging-sdl will have to resolve that, and many other issues.

2. yeah, hooks is a good idea! we need to always make sure there's some 'unlocker' hook being included, or we risk having users boot up with no unlocker thing installed to unlock their rootfs

3. hmm, right now I think we should just keep osk-sdl as the default and not complicate pmb with the change. In the future maybe this could be specified by the UI meta package (e.g. 'console' UI might require an unlocker that is basically just 'cryptsetup', and so on)?

For explicitly testing unl0kr, the user could explicitly install it either with 'apk add' on a running system or specifying it in the 'extra packages' config to pmbootstrap. What do you think?

4. if the provides thing is working like I think it should, the user can just apk add the one they want and it should replace any other package that provides the same virtual package

By clayton craft on 2021-11-21T18:36:42

For explicitly testing unl0kr, the user could explicitly install it either with 'apk add' on a running system or specifying it in the 'extra packages' config to pmbootstrap. What do you think?

Ah ok. Yeah, that sounds ok then.

if the provides thing is working like I think it should, the user can just apk add the one they want and it should replace any other package that provides the same virtual package

Oh cool. I didn't know that adding directly replaces the other package in this case.

So with that in mind, I suppose the next step would be to tweak postmarketos-mkinitfs to not hard-code the osk-sdl files anymore. One thing that might complicate this a little is that in addition to osk-sdl itself, postmarketos-mkinitfs also copies directfb, tslib and mesa .so libs. Is it ok to provide all of these through a hook in the osk-sdl package?

By Johannes Marbach on 2021-11-21T19:15:56

Oh cool. I didn't know that adding directly replaces the other package in this case.

Well, I'm like 94% sure that's the case

One thing that might complicate this a little is that in addition to osk-sdl itself, postmarketos-mkinitfs also copies directfb, tslib and mesa .so libs. Is it ok to provide all of these through a hook in the osk-sdl package?

Yeah that's conditional on whether or not osk-sdl is being copied, and the mesa libs are included only if osk-sdl and mesa_driver is set in deviceinfo.

In the case where mesa_driver is not set, we don't necessarily want mesa libs in the initfs when osk-sdl is there, because dfb can't use it and it takes up more space. I don't think there's a way to handle that situation nicely in a file hook thing...

On the other hand, if osk-sdl is on its way out the door, we could probably afford to do things a bit inefficiently for some cases that use osk-sdl if it means simplifying the mkinitfs + initfs.sh stuff long term.

It might be worth trying to have a call together to talk through this a bit more, since I'm sure that I'm also forgetting some aspects of this

By clayton craft on 2021-11-21T19:15:56

In the case where mesa_driver is not set, we don't necessarily want mesa libs in the initfs when osk-sdl is there, because dfb can't use it and it takes up more space. I don't think there's a way to handle that situation nicely in a file hook thing...

Oh, it depends on deviceinfo. Hm, yeah that probably won't work via a file hook then. Not sure if it'd be worth to define yet another type of hook that is a script printing out the files to include?

It might be worth trying to have a call together to talk through this a bit more, since I'm sure that I'm also forgetting some aspects of this

Yeah, good idea. My day is ending here but we can sync up on Matrix for some time next week maybe.

By Johannes Marbach on 2021-11-21T20:19:24

mentioned in merge request pmbootstrap!2154 (merged)

By Johannes Marbach on 2021-12-30T19:22:23

mentioned in issue pmbootstrap#2092 (closed)

By Johannes Marbach on 2022-01-04T19:23:43

closed with commit 816937b1

mentioned in commit 816937b1

By Johannes Marbach on 2022-02-05T07:45:45