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.
signature.asc
Description: PGP signature
