clone 361539 -1 reassign -1 gnupg thanks On Fri 2008-09-19 06:14:31 -0400, Jonathan McDowell wrote:
> I agree. However the bug you've followed up to is assigned to the
> debian-keyring package, whereas the issue really seems to be gpg's
> behaviour.
Hrm, yes you're right about that. It affects the usefulness of the
debian-keyring package, but it does look to be a bug in GPG instead.
I'm cloning this bug. Feel free to close the clone, if you think i've
done this improperly. (i wasn't sure if i should assign the clone to
gnupg or gnupg2, as both seem to have the same misbehavior; is another
clone warranted?)
> I think GPG probably wants to do something like:
>
> 1 GPG should understand about read-only keyrings.
> 2 Read/write keyrings should be checked for keys before read-only
> keyrings.
> 3 If a key in a read-only keyring is updated then the result should be
> written to a read/write keyring (which will then take precedence over
> the read-only one thanks to 2)
I think this misses some nuance that GPG needs. For example, if a key
that is present in a r/w keyring has no certifications on it, but
there *are* certifications on it in a r/o keyring, you'd like to be
able to evaluate the r/o certifications, even though the key was found
in the first keyring.
> Also possibly it should be reading all keyrings always for keys and
> combining them, which would allow the system keyring to be updated and
> users who've updated keys contained in it to automatically get more
> updates.
I think this is the right way to go.
Keyrings are basically simple aggregations of various certifications
about a particular key or key+UserID association. Each certification
that is aggregated is a distinct OpenPGP packet, bound by its
structure and contents to the relevant key or key+UserID.
If gpg wants to look for or evaluate a particular certification (or
type of certification), it should search in *both* the r/w keyrings
and the r/o keyrings. I'm not sure that the order matters, as long as
the certifications are valid. There are ways of resolving precedence
between two certifications (e.g. which one was issued later) that
should be *more* relevant than the writability of the keyring in which
the certification is stored.
If gpg wants to *add* a new certification to a key or key+UserID (via
--recv, --sign-key, --lsign-key, --import, --edit-key, etc), it should
ensure that the key itself and any relevant User IDs and
self-signatures are placed in the r/w keyring (copying from the r/o
keyring, if needed). Then it should place the new certification into
the r/w keyring, attached to the relevant point. Transferring the
subject material (key, UserID, and self-sigs) ensures that if the r/o
keyring goes away at some point (or was only there temporarily in the
first place), you'll still have a valid r/w keyring.
> Having had a look at the bugs on gnupg I think 38857 and 48077 are worth
> a look. It's interesting that Werner Koch is saying in 38857 that the
> ability to have multiple keyrings will be dropped in the future, though
> this was back in 2005.
Thanks for the pointers; if removing support for multiple keyrings is
actually a design goal, it would be a real shame. But it doesn't seem
to be acted on, since the man page for gpg2 (first released in 2006,
well after the remark you note) contains several references to
multiple keyrings.
--dkg
pgp7nloxZOTUt.pgp
Description: PGP signature
