Janusz A. Urbanowicz
alex at bofh.torun.pl
Sat Oct 2 20:45:02 CEST 1999
Some of this was discussed lately.
I use Debian system which has some predistributed keyrings in /usr/share
Today I started cleaning up my keyrings and I thought about removing
unnecessary keys that are duplicated in my private public keyring. So I set
up keyrings section like this:
I had to set my keyring like this to avoid GPG trying to add keys into one
of the /usr/share keyrings which are read-only to me. And this is
inconvenenient because gpg lists keys in keyring order so 'my' keys are at
the end, but this is because of GPG behavior of adding to last keyring.
I was also disappointed to see that with specifying keyring option GPG
'forgot' about default keyring in .gnupg.
So here's my proposition (for 1.0.1 or 1.2 ?):
Splitting keyring option into keyring and additional-keyring.
Keyring should work as it works now. Additional-keyring would specify
'library' keyring that is (possibly) read-only and not user's main keyring
(keys should not be imported into this keyring). Like those keyrings in
Debian, company keyring, anon-remailers database, or something else that the
user do not want to put into his main keyring and use everyday.
Additional-keyring should not override default keyring settings. If key is
avaliable both in standard and additional keyring, the standard one should
be used. Key disabling (and revocation ?) should apply to both keyrings.
This option should be also settable in system-wide options file (in case
such a feature will ever exist). This way admins could keep system-wide
keyrings by default avaliable to all users (I know all caveats of using GPG
in a multiuser environment, but for verifying signatures I think its The
Right Thing - esp considering also proposed keyring priority), distributions
could ship with pre-set maintainers' keyrings, and so on.
* | Janusz A. "Alex" Urbanowicz, | DSS: 1024/0x21939169
--+~| | http://eris.phys.uni.torun.pl/~alex/ | D-H: 2048/0xA2E48564
\_|/ | |_ RSA: 512/0xAB425659
| | "Sztuka jest zorganizowaną formą rozpaczy"
More information about the Gnupg-devel