[pkg-cryptsetup-devel] Bug#901795: cryptsetup-initramfs: please provide documented shell functions to validate/sanitize cryptroot entries in 3rd party hook files

[Guilhem Moulin]

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.
-------------- 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/20210909/342824f2/attachment.sig>