[pkg-cryptsetup-devel] Bug#901795: cryptsetup: new version may break 3rd party keyscripts (and thus boot)

Christoph Anton Mitterer calestyo at scientia.net
Mon Jun 25 04:19:48 BST 2018


On Tue, 2018-06-19 at 00:26 +0200, Guilhem Moulin wrote:
> Thus lowering the bug severity to ‘wishlist’ and retiling the bug
> accordingly.
Well... it still broke some existing setups... it was always advertised
that people could make their own keyscripts and they simply used what
seemed usable and provided by cryptsetup ;-)

Guess that's why you saw quite a number of reports of people that saw
their stuff breaking... but anyway I don't really care which severity a
bug has, as long as there's going to be a nice solution :-)





> FWIW, what we're currently doing (so far undocumented and subject to
> change) is to go through the system crypttab(5) and copy each entry
> requiring unlocking at initramfs stage to $DESTDIR/cryptroot/crypttab
> (the format of which is therefore analogous to crypttab(5)).  So the
> following template should work when the hook file has ‘cryptroot’ as
> prerequisite:
> 
>     . /lib/cryptsetup/functions
> 
>     [ -s "$DESTDIR/cryptroot/crypttab" ] || return 0
>     while read CRYPTTAB_NAME CRYPTTAB_SOURCE CRYPTTAB_KEY
> CRYPTTAB_OPTIONS; do
>         if [ "${CRYPTTAB_NAME#\#}" = "$CRYPTTAB_NAME" ] && \
>                 crypttab_parse_options "$CRYPTTAB_OPTIONS" n; then
>             […]
>         fi
>     done <"$DESTDIR/cryptroot/crypttab"

Will that process only those crypttab entries which actually require to
be processed during initramfs?


> But please note that this is subject to change until we document the
> snippet and close this bug :-P

Any idea already when this "API" is going to be stabilised? I'd prefer
to only adapt my stuff (&upgrade) once this is done. :D



One off topic things...
Why the whole split into cryptsetup-initramfs? Seems a bit overkill and
cosmetically less nice to me.

Wouldn't it have been the best if the cryptsetup initramfs hooks simply
only add stuff to the initramfs, if this was required for booting (or
didn't they do this already?), without any need to "configure/enable"
this by installing a package.
Right now this seems a bit error prone and kinda abusing the package
management for what should be rather configuration.

And if someone would have wanted to disable cryptsetup's initramfs-
tools integration, one could have simply provided a config file which
is sourced by the hooks and then exit if desired (or even better,
initramfs-tools should provide some masking mechanism,... like systemd
does when one adds symlinks to /dev/null in /etc/... with the same name
as the unit file shipped by the package in /usr/...


Cheers,
Chris.



More information about the pkg-cryptsetup-devel mailing list