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

[Arnaud Ferraris]

Hi,

Le 12/09/2023 à 10:30, undef via Debian-on-mobile-maintainers a écrit :
> 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.
> 

That sounds like an interesting idea indeed! This could be done by 
turning osk-sdl into a transitional package, which would depend on 
unl0kr, and would ship the symlink itself.

A few additional checks should probably be performed in maintainer 
scripts to ensure users won't end up with an unusable system unless 
doing something stupid (like removing both osk-sdl and unl0kr).

Cheers,
Arnaud

> 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-maintainers at 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-maintainers at 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-maintainers at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-on-mobile-maintainers

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/debian-on-mobile-maintainers/attachments/20230918/80314a56/attachment.sig>