key sig notation data in --with-colon mode?

[David Shaw]

On Sun, Oct 02, 2005 at 12:45:07AM +0200, Marcus Brinkmann wrote:
> At Sat, 1 Oct 2005 17:14:49 -0400,
> David Shaw wrote:
> > 
> > On Sat, Oct 01, 2005 at 10:54:30PM +0200, Marcus Brinkmann wrote:
> > > Hi,
> > > 
> > > currently, gnupg does not emit any key signature notation data on the
> > > status fd (while data signature notation data _is_ output at verify).
> > > 
> > > In fact, policy URL and notation data handling is suspiciously absent
> > > from list_keyblock_colon().  Are there any plans to fill that gap?
> > 
> > It is in there.  A while back there was a good bit of discussion
> > around the problem of subpackets, including notations and policy URL.
> > There was also some concern about future expansion and the need for
> > adding new flags each time OpenPGP added a new packet type.  It ended
> > up as a single generic way to list any subpacket type.  This lists all
> > possible subpackets:
> 
> If this is the case, then it should be done in a consistent manner.
> Which means to me at least the following:
> 
> * 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.

> * 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.

> 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.

> One solution to this is to split out the shared code into a library.
> The library interface would provide the necessary level of
> abstraction[1].  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 ;)

David