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.
