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

[Guilhem Moulin]

On Mon, 25 Jun 2018 at 05:19:48 +0200, Christoph Anton Mitterer wrote:
> 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 ;-)

Sure, people are welcome to write their own keyscripts.  But rather than
using an undocumented interface and assume it'll never break, the right
thing to do is to ask us to document said interface and commit to
maintain it.
 
> Guess that's why you saw quite a number of reports of people that saw
> their stuff breaking...

Uh, are you referring to the regressions that were filed last week?  You
can't compare your own #901795 with these regressions, where we broke
setups following the documented interface…

Beside your bug, the only similar issue we heard of was reported to the
list by Marc Haber, who wrote he was “aware that [he's] using an
internal interface, hence not a bug report but this message”.

That being said, 2 reports doesn't mean there are only 2 users affected.
But I think it's fair to assume that the very vast majority of users
were not using our internal interface. 

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

Yes.
 
>> 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?

Right now we'd like things to settle a bit, and fixing actual regression
have higher priority.  I'll plan to start working on this once the
package enters testing, but I'm not promising anything.
 
> 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.

See the changelog entry for 2:2.0.3-1, and the 2 merged bug it closed.
 
> 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/...

See /etc/cryptsetup-initramfs/conf-hook.  We're deprecating
CRYPTSETUP=[y|n] now that the we split the initramfs integration in its
own package, though.

-- 
Guilhem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/attachments/20180625/69c618f5/attachment.sig>