Hi,

as suggested in the debian-keyring README, I've added the Debian keyrings
directly:

,----[ ~/.gnupg/gpg.conf ]
| keyring /usr/share/keyrings/debian-keyring.gpg
| keyring /usr/share/keyrings/debian-keyring.pgp
| keyserver wwwkeys.de.pgp.net
`----

Here's a typescript of what happens importing a key:

penelope[nikolaus]$ gpg --recv-keys XXXXXXXX
gpg: requesting key XXXXXXXX from hkp server wwwkeys.de.pgp.net
gpg: key XXXXXXXX: public key "<id>" imported
gpg: can't create `/usr/share/keyrings/debian-keyring.gpg.tmp': Read-only file system
gpg: failed to rebuild keyring cache: file open error
gpg: can't create `/usr/share/keyrings/debian-keyring.pgp.tmp': Read-only file system
gpg: failed to rebuild keyring cache: file open error
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:	1  signed:   0	trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: Total number processed: 1
gpg:		   imported: 1
penelope[nikolaus]$


Have a nice day,
Nikolaus

Nikolaus Schulz <microschulz@web.de> wrote:

Hi Nikolaus,

I think this is not a bug.  You just missed the next paragraph in the
README, telling you

,----
| GPG cannot modify keys in these root-owned files.  In order to edit or
| sign keys in the Debian keyring you will first need to import them to
| your personal keyring.  If ~/.gnupg/gpg.conf lists the debian-keyring
| files, keys already in the Debian keyring will not be imported to your
| personal keyring.  You can use "gpg --no-options --import" to force
| GPG to ignore gpg.conf and import keys to your personal keyring only.
`----

Should we close this bug?

Regards, Frank

Hi Frank!

Frank Küster wrote:

Hmm.  I'm not very fluid with gnupg, but first, the README section you're
citing starts with the clear statement:

,----[ README ]
| Using the debian-keyring with gpg
| ---------------------------------
|
| Add these lines to the bottom of your ~/.gnupg/gpg.conf[1] file:
|
| keyring /usr/share/keyrings/debian-keyring.gpg
| keyring /usr/share/keyrings/debian-keyring.pgp
`----

And this _does not work_.

    Second, I may be lacking the necessary insight how gnupg works, but
IIRC, when I included the given "keyring" lines in ~/gpg.conf,  it was
not the procedure of "editing or signing keys in the Debian keyring"
that failed, but the procedure of importing (any) keys in my private
keyring.  This is different from what the paragraph you cited speaks
about.

HAND,
Nikolaus

Hello,

I'm just seeing this from time to time in mutt. While trying to validate
a signature I get this output. It would be great to have at least a
workaround for this.

Regards,
Andrei

This is a significant problem for me as well.

There are reasonable circumstances where a system administrator would
want users to always have access to a system-maintained keyring.  The
users should of course also have no problems simultaneously
manipulating and updating their own user-controlled keyring.

The natural way to perform such a split is to do as the README
suggests, and add extra keyring lines to ~/.gnupg/gpg.conf

However, with this configuration, even simple keyserver fetches for
non-privileged users look like this:

0 wt215@squeak:~$ cat .gnupg/gpg.conf
keyring /usr/share/keyrings/debian-keyring.gpg
0 wt215@squeak:~$ gpg --keyserver keys.gnupg.net --recv d21739e9
gpg: requesting key D21739E9 from hkp server keys.gnupg.net
gpg: key D21739E9: public key "Daniel Kahn Gillmor <dkg@fifthhorseman.net>" imported
gpg: can't create `/usr/share/keyrings/debian-keyring.gpg.tmp': Permission denied
gpg: failed to rebuild keyring cache: file open error
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   2  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 2u
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
2 wt215@squeak:~$

The leading number in the shell prompt indicates the return code from
the last command, so this apparent successful import is returning with
code 2.  According to gpg(1), that means a "fatal error":

  RETURN VALUE
       The program returns 0 if everything was fine, 1 if at least a
       signature was bad, and other error codes for fatal errors.

Even more confusing, the result does not seem to be consistent.
Running the same command a second time looks like this:

0 wt215@squeak:~$ gpg --keyserver keys.gnupg.net --recv d21739e9
gpg: requesting key D21739E9 from hkp server keys.gnupg.net
gpg: key D21739E9: "Daniel Kahn Gillmor <dkg@fifthhorseman.net>" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1
0 wt215@squeak:~$

Is there a diagnosis for what's causing this problem?  Is there a
better way to accomplish the goal i outlined above of having a
system-maintained keyring *and* a user-maintained keyring?  Is this
associated with any upstream bug?

The only related upstream issue i could find was here:

https://bugs.g10code.com/gnupg/issue514

which Werner closed as "not a bug" -- but without addressing the
underlying need to be able to include system-maintained keyrings
during regular use.

Thanks for maintaining gpg in debian,

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.

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)

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. Or maybe it should just look at read-only keyrings for a
--recv-key.

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.

J.

clone 361539 -1
reassign -1 gnupg
thanks

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

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.

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.

Date: Wed, 28 Mar 2012 13:55:28 -0400 >From: Samuel Bronson >-------------
SGkgRnJhbmshCgpGcmFuayBLw7xzdGVyIHdyb3RlOgo+IE5pa29sYXVzIFNjaHVseiA8bWljcm9zY2h1bHpAd2ViLmRlPiB3cm90ZToKPiAKPiA+IFBhY2thZ2U6IGRlYmlhbi1rZXlyaW5nCj4gPiBWZXJzaW9uOiAyMDA1LjA1LjI4Cj4gPiBTZXZlcml0eTogbm9ybWFsCj4gPgo+ID4gSGksCj4gPgo+ID4gYXMgc3VnZ2VzdGVkIGluIHRoZSBkZWJpYW4ta2V5cmluZyBSRUFETUUsIEkndmUgYWRkZWQgdGhlIERlYmlhbiBrZXlyaW5ncwo+ID4gZGlyZWN0bHk6Cj4gPgo+ID4gLC0tLS1bIH4vLmdudXBnL2dwZy5jb25mIF0KPiA+IHwga2V5cmluZyAvdXNyL3NoYXJlL2tleXJpbmdzL2RlYmlhbi1rZXlyaW5nLmdwZwo+ID4gfCBrZXlyaW5nIC91c3Ivc2hhcmUva2V5cmluZ3MvZGViaWFuLWtleXJpbmcucGdwCj4gPiB8IGtleXNlcnZlciB3d3drZXlzLmRlLnBncC5uZXQKPiA+IGAtLS0tCj4gPgo+ID4gSGVyZSdzIGEgdHlwZXNjcmlwdCBvZiB3aGF0IGhhcHBlbnMgaW1wb3J0aW5nIGEga2V5Ogo+ID4KPiA+IHBlbmVsb3BlW25pa29sYXVzXSQgZ3BnIC0tcmVjdi1rZXlzIFhYWFhYWFhYCj4gPiBncGc6IHJlcXVlc3Rpbmcga2V5IFhYWFhYWFhYIGZyb20gaGtwIHNlcnZlciB3d3drZXlzLmRlLnBncC5uZXQKPiA+IGdwZzoga2V5IFhYWFhYWFhYOiBwdWJsaWMga2V5ICI8aWQ+IiBpbXBvcnRlZAo+ID4gZ3BnOiBjYW4ndCBjcmVhdGUgYC91c3Ivc2hhcmUva2V5cmluZ3MvZGViaWFuLWtleXJpbmcuZ3BnLnRtcCc6IFJlYWQtb25seSBmaWxlIHN5c3RlbQo+IAo+IEhpIE5pa29sYXVzLAo+IAo+IEkgdGhpbmsgdGhpcyBpcyBub3QgYSBidWcuICBZb3UganVzdCBtaXNzZWQgdGhlIG5leHQgcGFyYWdyYXBoIGluIHRoZQo+IFJFQURNRSwgdGVsbGluZyB5b3UKPiAKPiAsLS0tLQo+IHwgR1BHIGNhbm5vdCBtb2RpZnkga2V5cyBpbiB0aGVzZSByb290LW93bmVkIGZpbGVzLiAgSW4gb3JkZXIgdG8gZWRpdCBvcgo+IHwgc2lnbiBrZXlzIGluIHRoZSBEZWJpYW4ga2V5cmluZyB5b3Ugd2lsbCBmaXJzdCBuZWVkIHRvIGltcG9ydCB0aGVtIHRvCj4gfCB5b3VyIHBlcnNvbmFsIGtleXJpbmcuICBJZiB+Ly5nbnVwZy9ncGcuY29uZiBsaXN0cyB0aGUgZGViaWFuLWtleXJpbmcKPiB8IGZpbGVzLCBrZXlzIGFscmVhZHkgaW4gdGhlIERlYmlhbiBrZXlyaW5nIHdpbGwgbm90IGJlIGltcG9ydGVkIHRvIHlvdXIKPiB8IHBlcnNvbmFsIGtleXJpbmcuICBZb3UgY2FuIHVzZSAiZ3BnIC0tbm8tb3B0aW9ucyAtLWltcG9ydCIgdG8gZm9yY2UKPiB8IEdQRyB0byBpZ25vcmUgZ3BnLmNvbmYgYW5kIGltcG9ydCBrZXlzIHRvIHlvdXIgcGVyc29uYWwga2V5cmluZyBvbmx5Lgo+IGAtLS0tCgpIbW0uICBJJ20gbm90IHZlcnkgZmx1aWQgd2l0aCBnbnVwZywgYnV0IGZpcnN0LCB0aGUgUkVBRE1FIHNlY3Rpb24geW91J3JlCmNpdGluZyBzdGFydHMgd2l0aCB0aGUgY2xlYXIgc3RhdGVtZW50OiAKCiwtLS0tWyBSRUFETUUgXQp8IFVzaW5nIHRoZSBkZWJpYW4ta2V5cmluZyB3aXRoIGdwZwp8IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQp8CnwgQWRkIHRoZXNlIGxpbmVzIHRvIHRoZSBib3R0b20gb2YgeW91ciB+Ly5nbnVwZy9ncGcuY29uZlsxXSBmaWxlOgp8Cnwga2V5cmluZyAvdXNyL3NoYXJlL2tleXJpbmdzL2RlYmlhbi1rZXlyaW5nLmdwZwp8IGtleXJpbmcgL3Vzci9zaGFyZS9rZXlyaW5ncy9kZWJpYW4ta2V5cmluZy5wZ3AKYC0tLS0KCkFuZCB0aGlzIF9kb2VzIG5vdCB3b3JrXy4gCgo+IFNob3VsZCB3ZSBjbG9zZSB0aGlzIGJ1Zz8KCiAgICBTZWNvbmQsIEkgbWF5IGJlIGxhY2tpbmcgdGhlIG5lY2Vzc2FyeSBpbnNpZ2h0IGhvdyBnbnVwZyB3b3JrcywgYnV0CklJUkMsIHdoZW4gSSBpbmNsdWRlZCB0aGUgZ2l2ZW4gImtleXJpbmciIGxpbmVzIGluIH4vZ3BnLmNvbmYsICBpdCB3YXMKbm90IHRoZSBwcm9jZWR1cmUgb2YgImVkaXRpbmcgb3Igc2lnbmluZyBrZXlzIGluIHRoZSBEZWJpYW4ga2V5cmluZyIKdGhhdCBmYWlsZWQsIGJ1dCB0aGUgcHJvY2VkdXJlIG9mIGltcG9ydGluZyAoYW55KSBrZXlzIGluIG15IHByaXZhdGUKa2V5cmluZy4gIFRoaXMgaXMgZGlmZmVyZW50IGZyb20gd2hhdCB0aGUgcGFyYWdyYXBoIHlvdSBjaXRlZCBzcGVha3MKYWJvdXQuCgpIQU5ELCAKTmlrb2xhdXMKCg