Control: tag 891410 pending Guilhem Moulin wrote...
> Hmm. I guess I'm part of the problem since I haven't found time to help
> with this unfortunately, but on a quick look it appears that my comments
> from msg#27 and msg#32 still hold.
>
> cryptsetup's initramfs integration isn't part of cryptsetup upstream,
> but is development and maintained by the Debian packaging team, which
> I'm part of. AFAICT clevis upstream seem to have taken shell scripts
> from src:cryptsetup and adapted them to their needs. Might work right
> now, but these file use *internal* / *undocumented* interfaces which are
> subject to change without notice. I fear clevis initramfs users have a
> real risk of ending up with an unbootable system when we do update these
> interfaces.
Unterstood.
As far as I understand however, while such a situation _can_ happen, it
is not very likely.
So my suggestions, in decreasing order of preference:
* Creating/using an API for the initramfs code, something you suggested in
another message. Honestly, I haven't checked the code yet whether this
is feasablle.
* Make sure clevis-initramfs is tested on a regular base. Implementing
it would be my job. If this can be done in autopkgtest, even better.
* Present a grim warning message during installation users should be
aware there might be a malfunction of either an clevis-initramfs or
initramfs update. Therefore, in a dist-upgrade, or when using testing/
unstable they should always make sure an alternative way for unlocking
exists.
But this in a way sheds a bad light on the Debian project, and
assuming breakage is not very likely to happen, the effect of such a
message is mostly creating disturbance first, later ignorance. By
experience, this is the moment when things break.
For the moment I'll mostly likely do an upload to experimental. I've
been waiting for this feature for a long time, therefore I'd like to
collect first experiences with it soon. We should have a sound solution
before the freeze which is still several months away.¹
Thanks a lot for keeping an eye on this, much appreciated.
Regarcs,
Christoph
¹ But keep in mind dates in calendars are closer than they appear.
signature.asc
Description: PGP signature
