How about "--with-packet-data" instead?

[Michael Young]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[I apologize for reopening this thread after several weeks...
work and travel have kept me tied up.]

In response to my suggestion for a "--with-packet-data" switch that
would include the full OpenPGP packets (rather than just the key
material, as "--with-key-data" does now), David Shaw responded:

> How is this different than (for example) pgpdump?  It seems better to
> keep this as a seperate utility than building it into GnuPG where it
> wouldn't really serve a purpose the majority of the time.

The difference is that the GnuPG command output can include GnuPG's
trust calculation, *correlated* with the keyring (packet) material.
Even when the trustdb is exported in an interchange format,
that won't be enough.

The ultimate goal that drove my suggestion was to be able to
mechanically edit invalid material out of a keyring, without
having to resort to the baroque --status-fd gadgetry.  [My
particular interest is being able to use the resulting
export/keyring with a program that has an inadequate trust
model itself (for example, none at all).  But, I think this
could be more generally useful for preening useless material
(for example, junk acquired from keyservers automatically).]

This would be relatively easy if the output from
    "--list-keys --with-colons --fixed"
put names in the same order that "--edit-key" uses.
That has not been the case in the past.  [I've seen a claim that
the orderings will match in a future release.  This may be
my final solution.]

It would even be passable if names were in the same order that they
appear in the keyring.  Then, I *could* use a tool like "pgpdump" to
do the editing.

But, the ordering aren't correlated, so I've suggested a couple of
minor options to help me achieve my goal:
    an "--export-option" to exclude "untrusted" material; or,
    a "--with-packet-data" to emit the whole OpenPGP packet.

I realize that these aren't common needs, but that's true of a large
proportion of the interface options.  I really don't think either
option would be more obscure than other existing ones.

I can suggest yet another approach, but I think it's less clean than
my first two: an "--export-option" to include trust values encoded in
comment packets.  PGP did this in its internal keyring representation,
in the form of "trust packets".  This isn't part of the OpenPGP
specification, but it's not without precedent (and it looks a lot
like another existing quirky switch, "--sk-comments").  For my
purposes, I would need "trust" (including what PGP calls "validity")
information on all of the components (keys, names, photos, subkeys),
not just keys.

As always, I'm open to other suggestions on a way to solve my problem
that doesn't require great contortions or unreasonable interface
additions.  Thanks again for your help.

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQA/AwUBPl6Xh+c3iHYL8FknEQKkkgCg+EA9eKsb+i/g8ZxzrQnk7ybJ/pkAn1e5
pvLVTmLIUDkrbG7j5097x7FZ
=gB23
-----END PGP SIGNATURE-----