Should cope better with read-only keyrings
Open, WishlistPublic

Description

There is an often reported wish in the Debian bug-tracker, that gnupg should
cope better with read-only keyrings:

http://bugs.debian.org/38858
http://bugs.debian.org/48077
http://bugs.debian.org/318853
http://bugs.debian.org/499550

The main point behind this is, gnupg should be able to do read-only operations
on all keyrings (like validation), but operations including writing (recv-keys,
check-trustdb, ...) onlz on the kezrings with write access. The last mentioned
report contains an extensive look at the problem.

So what about introducing an option e.g. keyring-read, on which read operations
can be performed too. For write operations, these keyrings should be ignored.

What do you think?

Details

dleidert set External Link to http://bugs.debian.org/499550.Sep 6 2009, 3:46 PM
dleidert added a subscriber: dleidert.
werner added a subscriber: werner.Dec 4 2009, 3:36 PM

These bug reports are sometimes mixing two different issues: The
debian-keyring and r/o keyrings for other purposes.

The debian keyring is afaik used with gpgv and has the special
property that all keys in it are fully trusted. In short: It is a set
of keys only to be used by gpgv. Thus the issue is how to create this
keyring. Currently I suggest to use gpg --export LIST-OF-KEYIDS to
create it. In some distance future a little conversion tool might be
required to convert the OpenPGP transport format for keys into the
database format used by gpgv. The bottom line is that I don't see
that as an issue and the Debian readme seems to support this point of
view.

The other issue is that of multiple keyrings. Over the years we tried
several approaches to get it right but none of them worked reliable.
The problem is the usual one of keeping two databases in sync.
Aggravated by the requirement to keep some of them read-only but still
allowing to update them somehow. Approaches like preferring the
writable one over the read-only one work in theory but will lead to
administrative headaches. We will never be sure which keyblock is
actually used. (I had a similar problem today with VPATH builds where
two different header files, both are created from the same source,
provoked a bug in certain environments - not particular easy to
understand what was going on)

What I plan with GnuPG 2.1 is to rework the keyring situation by
replacing keyrings it with a new format (keybox). This new format
allows to keep meta data and also will boost key access times. This
will make it possible to flag keys as read-only or allow updates only
with a new options set. I am actually working on 2.1. However,
before we implement such extravagant feature it will be wetter to
collect real world use cases. We should do this on gnupg-devel@.

One such use case might be to automatically import certain keys into
the keybox for future use. This is basically the idea of reading the
writable keyring first and only then the read-only ring
(write-on-demand). The solution I have in mind is to import such
read-only keys using the established --auth-key-locate feature.

marcus added a subscriber: marcus.Jun 22 2017, 4:35 PM

@werner do you have any updates on this?