key sig notation data in --with-colon mode?
marcus.brinkmann at ruhr-uni-bochum.de
Sun Oct 2 03:00:50 CEST 2005
At Sat, 1 Oct 2005 19:46:32 -0400,
David Shaw wrote:
> > * There should be a status message SUBPACKET which outputs subpacket
> > data for example when verifying a signature. This should replace
> > the current status messages NOTATION_NAME and NOTATION_DATA (which
> > could be kept for backwards compatibility).
> I disagree with this. The status messages are used when handling a
> message - verifying a signature, or decrypting a message. They are
> not really used when listing keys. It would be odd at best to output
> signature subpackets to one file descriptor, while doing every other
> part of the key listing to another. If nothing else, it would be
> difficult to reassemble the two.
I think there was a misunderstanding. I said there should be a
SUBPACKET status message when verifying a signature, not when
keylisting. For example, this could be emit when verifying a message:
SUBPACKAGE 20:1:24:%80%00%00%00%00%09%00%07MyFOO at FOOABCDEFG
and this when keylisting:
spk:20:1:24:%80%00%00%00%00%09%00%07MyFOO at FOOABCDEFG
The motivation here is to have the same code for the same thing.
Currently, I have to parse this for subpackets at verify:
[GNUPG:] NOTATION_NAME AF at gnupg.org
[GNUPG:] NOTATION_DATA ZYX
Note that this does not even include all information. Notably all
flags are absent.
> > * There should be a way to set arbitrary subpackets. If I am not
> > mistaken, only policy URL and notation data can be specified, and
> > this using extra options which you say you want to avoid and which
> > need to be extended in the future, etc.
> You can set arbitrary subpackets. Just specify the subpacket numbers
> that you are interested in, separated by commas, or specify no number
> to get all subpackets. I only showed policy URL and notations in the
> example I gave as those were the two you mentioned.
Sorry, I was being vague. I actually meant to "set arbitrary
subpackets" as in "adding arbitrary subpackets to a signature". There
must be a way to write the subpackets, and the only ways I currently
know are the various policy URL and notation options to gpg, which are
quite limited. For example, I can't specify arbitrary binary data,
and I can't set or clear the human-readable flag.
Currently, we have (I think) a mix of specific, limited commands and
options, and a generic dump of the raw binary data. I think that's
> > However, I want to stress that I have concerns about this approach.
> > Most certainly you have considered all this before, but I want to
> > spell them out nevertheless.
> > * The result will inevitably be code duplication. Different
> > implementations could have different bugs, leading to inconsistent
> > results. IE, the user may see some notation data with gpg at the
> > command line, but different data in the MUA using GPGME.
> I'm not sure if I agree with this. Certainly there are two different
> ways to view notations, but they are also two different ways to USE
> notations: one is on a key signature (i.e. a selfsig or binding sig),
> and one is on a regular data signature.
I believe you, but I fail to see what it has to do with what I said,
but then, I was maybe not very clear to begin with. You are raising
semantic questions, but I was referring to straightforward
implementation bugs. For example, if a new flag is added to the
standard, it must be added to each and every program parsing the
notation subpacket. This is already the case, but in a top-down sort
of way, while adding subpacket parsers into each program allows for a
wider variety of bugs (and this is one place where I don't like a lot
of variety ;)
> > One solution to this is to split out the shared code into a library.
> > The library interface would provide the necessary level of
> > abstraction. Is it easier to write extensible library interfaces than
> > to write extensible user interfaces? I don't dare to guess at an
> > answer. But if you have hit the limit of command lines and status
> > messages, then going to a library is the next logical step. You seem
> > to want to move into this direction (at least this seems to be the
> > consequence of the approach you are taking, even if this was not your
> > intention).
> It's a good question. I do think that it is very difficult to make
> one program that serves all purposes: command line usage, usage from
> programs, library. Some of the oddities you are noting in GPG are
> from this effort to be all things for all usages. I would not be
> against an OpenPGP library. I usually avoid this question, as Werner
> and I respectfully disagree on the subject ;)
Actually, I am not really ambitious about this. But it seems to me
that a decision to only to import/export the raw subpacket data is
quite a deviation from the "design contract" that GPGME has with
GnuPG. I am not sure that is really intentional, maybe Werner can
Note that for me personally, implementing a subpacket parser is quite
possibly easier and less error-prone than all the status message and
option management. At the worst it is approximately the same effort.
I am not really having this discussion for a trivial 8 byte packet
format specifying two flags and two binary octet streams. What I am
trying to do here is to look at the matter in a "down the road" sort
of way. And starting to put RFC2440 parser logic into GPGME when we
have come such a long way without it seems a major deviation to me,
that potentially has big consequences if paradigmatized. Or maybe I
am just paranoid.
More information about the Gnupg-devel