Hi, On Thu, 09 Sep 2021 at 00:54:51 +0200, Christoph Anton Mitterer wrote: > I've just wondered whether the way you've mentioned above is still > valid respectively considered "stable" now (as it: for use by > keyscripts)? :-)
Well we've never received any follow-up regarding a stable interface and/or documented functions, so this bug is still open and the situation is not more stable than 3 years ago :-P The interface suggested in https://bugs.debian.org/901795#53 likely still works, but is still subject to change while this bug is open. > And further, did I understand it right, that > $DESTDIR/cryptroot/crypttab would contain one line (in the crypttab > syntax) per device that needs unlocking in the initramfs? Yes, however the exact TABFILE value may not be relied upon, and the file content is mangled to make it suitable for initramfs stage, so it might not match /etc/crypttab. > And obviously I should e.g. do the copy_exec only once. copy_exec() is a no-op when the destination exists. > Or is there a better way? I've seen crypttab_foreach_entry()... > > Could I use that like this: > > myhook() > { > #- parses CRYPTTAB_KEY > #- set variables whether it needs to copy stuff in > } > > crypttab_foreach_entry(myhook) > > if [ $foo = "yes" ]; then > copy_exec whatever > fi > > AFAIU, that function would also automatically detect whether it's in a > hook context, and set the right TABFILE? Yes, again see https://bugs.debian.org/901795#53 , that's what /usr/share/initramfs-tools/hooks/cryptgnupg and some of our other hooks do. -- Guilhem.
signature.asc
Description: PGP signature