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

[Christoph Anton Mitterer]

On Sat, 2021-09-11 at 17:55 +0200, Guilhem Moulin wrote:
> we have no reason to assume that the opaque 3rd field value is
> $FOO-delimited.  For all I know there might be keyscripts which
> expect a
> JSON string here instead…

Well sure... or it could be base64 encoded, XML or whatever.

Question is though: What makes sense to provide to programmers of
keyscripts?

Will such developer insist on using format XYZ if he's already provided
with out-of-the-box tools for some other format ABC and that's enough
for his needs?

I would have thought that the whole system benefits if one tries to
keep things as homogeneous as possible with an API that handles things
in a stable way and users don't have to adapt their keyscripts
everytime something changes in the back.

I doubt it's so beneficial to treat it as fully opaque and let
everything like escaping be done differently per keyscript.


> I wouldn't mind documenting _CRYPTTAB_KEY for
> those who need the raw value from crypttab(5), but even without the
> ambiguity can easily be eliminated by double-escaping or simply using
> other escape sequences: “foo\040bar:ba%3Az” in crypttab yields
> CRYPTTAB_KEY="foo bar:baz%3Abar" which you can trivially decode into
> a
> pair ["foo bar", "ba:z"].

Well sure I can one can do it the keyscript. I could simply take the
example crypttab_parse_key_as_options() given before and put that into
the keyscript.
My point was rather that this ain't a wheel every keyscript developer
should need to re-invent.

But anyway... I guess that leads to nothing.


I guess documenting _CRYPTTAB_* as stable API would be helpful, from
there all keyscript developers could re-do the some similar kind of
parsing.
But it probably only makes sense if the crypttab_*() functions would
also get ever official, which currently doesn't seem on the near
horizon.



Well, from my side we could probably close the bug or at least I can
unsubscribe it, since there doesn't seem to be any clear path forward
to really stabilise that API and there's no desire to extend it either.

I will just "unofficially" use what's already and adapt should it ever
break :D


Thanks for you help,
Chris.