[Debian-on-mobile-maintainers] Bug#1051465: unl0kr: Lacks automated migration when osk-sdl is already installed

[Arnaud Ferraris]

Le 09/09/2023 à 11:27, undef via Debian-on-mobile-maintainers a écrit :
> Thanks for getting the ball rolling on this one.
> 
> I think in the first instance we should switch c-s-m to unl0kr to catch 
> new installs as you say. That'll stop the problem from getting worse. It 
> would probably be a good idea to ask more technical users to make the 
> switch too before making this type of change.

Yes, I believe this should be done ASAP as I think currently there's 
only the 2 of us actively using unl0kr, so getting it into more hands 
will likely help catch bugs and make it more stable.

> 
> After that, I have a couple of thoughts on the automated transition:
> 
> 1. If unl0kr is installed while osk-sdl is it should probably do 
> nothing. This avoids breaking working installs.

This is fine for now, but I think it should be revisited at some point 
in the future (ideally pre-trixie release, see below).

> 
> 2. If unl0kr is installed and osk-sdl isn't it should check for 
> osk-sdl's debconf setting indicating that c-s-m or similar configured 
> crypttab in the first place. If this is set unl0kr could attempt to add 
> its keyscript to the crypttab.
> 
>      a. This probably also requires a release of osk-sdl with the 
> inverse to:
> 
>          * Deconfigure itself
> 
>          * Configure unl0kr
> 
>          * Set unl0kr's debconf flag as osk-sdl's is.

That sounds reasonable indeed.

> 
> 3. A new install of unl0kr without osk-sdl ever having been installed 
> could either:
> 
>      a. Do nothing, leaving the package installed in a dormant state as 
> it is now.
> 
>      b. Prompt loudly using debconf then automatically attempt to 
> configure (this is somewhat recommended against in debconf's docs).
> 
>      c. Just automatically attempt to configure (negating the need for 2).
> 
> 
> I'm somewhat reticent to do 3c as this will break installs that are 
> non-standard (say someone's configured a TPM or yubikey unlock), but 
> there is at least some desire for the package automatically configuring 
> the system: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028554

I think that 3a is the best option here, as it basically matches the 
current behaviour of osk-sdl, which is just fine.

> 
> 
> That leaves the matter of how do we trigger the switch? Currently the 
> only packages installed indicating FDE on Mobian devices are unl0kr and 
> osk-sdl. I can't think of a neat way to cause one to be removed and 
> replaced with the other without triggering the install on non-FDE devices.

I'm leaving the "how" aside for now, rather discussing the "why" here: 
IIUC osk-sdl is now unmaintained and will likely stay that way; 
therefore, as it's a rather critical component (in the sense that it 
deals with secrets/encryption) I believe it shouldn't be part of the 
upcoming Trixie release.

New installs (after the upcoming c-s-m changes are in) won't be 
affected, which is already a good thing; but I'm a bit reluctant to 
leave existing users with an unmaintained critical component, hence my 
belief that an automated migration would be nice.

As suggested by the bug severity this isn't an urgent matter though, and 
the idea of dropping osk-sdl for trixie can also be discussed.

Cheers,
Arnaud

PS: osk-sdl could be made a transitional package at some point, which 
would depend on unl0kr, and would take care of modifying the crypttab so 
unl0kr is used instead.

> 
> 
> _______________________________________________
> Debian-on-mobile-maintainers mailing list
> Debian-on-mobile-maintainers at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-on-mobile-maintainers