I seem to have dropped the BTS on reply, so including the history in
this email.
Another option I realized might work is to add a `breaks` and `replaces`
osk-sdl in unl0kr then ship a link from the osk-sdl keyscript to the
unl0kr one in unl0kr. I haven't tested anything at this point, but this
would mean we don't have to modify people's crypttab.
Some potential issues for this option:
* It would require an update to osk-sdl to make sure the crypttab config
isn't removed if unl0kr is also installed.
* A user removing osk-sdl manually then installing unl0kr would need to
configure things manually. Then again, neither would 3a below.
On 9/9/23 21:04, Arnaud Ferraris wrote:
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-maintain...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-on-mobile-maintainers
_______________________________________________
Debian-on-mobile-maintainers mailing list
debian-on-mobile-maintain...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-on-mobile-maintainers
