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