coping with unknown keywords on --status-fd
wk at gnupg.org
Sat Sep 17 13:21:34 CEST 2016
On Sat, 17 Sep 2016 11:16, neal at walfield.org said:
> I'm not sure your suggestions are the best way to address Daniel's
> concerns. In his original mail, he writes:
> What does "prepared to see" mean? does it mean "can safely ignore"
> [unknown keywords]?
Don't bail out on unknown keywords. There is no requirement to act on
everything. Remember what Jon Postel said:
TCP implementations should follow a general principle of robustness:
be conservative in what you do, be liberal in what you accept from
This rule turned out to be major success story for the Internet (in
contrast to OSI) and has been codified in RFC-1122 (Requirements for
Internet Hosts -- Communication Layers). Agreed: In certain security
protocol parts you need to be much more stricter - but this is what gpg
encapsulates for you.
> I think renaming --status-fd to deal with this is disproportionate and
> ought to be avoided. Also, I don't see how renaming a keyword would
I mentioned this to show how it would be possible to make applications
using a newer gpg version fail - in the case gpg breaks the interface.
Note that there has only been one interface break in the last 18 years:
The removal of the --fixed-list-mode option in 2.1 - after it was
introduced in 2001. And that has nothing to do with the status-fd
output - the status-fd output has only be enhanced.
The experience in X.509 and OpenPGP is also that critical flags just
don't work. You simply claim that you understand them and go on with
This is all an non-issue. The real issue is that the majority of users
still avoid the --status-fd interface and encounter breakage all the
time; for example because they also forget to LC_ALL=C.
You can't magically fix wrong usage of a tool. Consider how many
scripts will fail on file or directory names with spaces or other
unusual but allowed characters. The only thing you can do is to explain
what to do.
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 162 bytes
Desc: not available
More information about the Gnupg-devel