[pkg-cryptsetup-devel] Bug#901795: cryptsetup-initramfs: please provide documented shell functions to validate/sanitize cryptroot entries in 3rd party hook files
Guilhem Moulin
guilhem at debian.org
Sat Sep 11 16:55:04 BST 2021
On Sat, 11 Sep 2021 at 17:12:17 +0200, Christoph Anton Mitterer wrote:
>>> For which fields are the octal escapes handled? The manpage only
>>> mentions them for them for the key/3rd field.
>>
>> My bad, it's supported in all fields.
>
> Are you going to correct it or shall I provide a patch for it?
I'll fix it, thanks for the notice!
>>> 4) Wishlist ;-)
>>> Can we have something like the option splitting for the key/3rd
>>> field,
>>> too?
>>
>> That's too much a niche case IMHO. When you use a key script the 3rd
>> field is an opaque value passed along and you might treat it any way
>> see fit.
>
> I would really really ... really ;-) strongly hope you'd reconsider
> this:
I still stand by what I wrote here 3 years ago, it's a useniche case and
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… 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"]. Moreover, doing this makes it possible to
manipulate binary strings which is not something we can do with
pre-mangled environment variables.
--
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/20210911/7fcca211/attachment.sig>
More information about the pkg-cryptsetup-devel
mailing list