keyrings and moving keys
Wed May 15 17:55:01 2002
Content-Type: text/plain; charset=us-ascii
Hi, all --
=2E..and then David T-G said...
% Perhaps as a result but perhaps simply coincidentally, any received keys
% end up in my primary ring instead of in the catch-all ring (or even the
% last ring listed). Gaack.
I think I have it all worked out. Boy o boy was this was brutal.
It appears that even if there is no options file and there is a keyring
explicitly listed on the command line, like
gpg --options /dev/null --keyring pubring.catch-all-keys.gpg --import
or so, the imported key will drop into the default pubring.gpg keyring.
Adding --no-default-keyring takes care of that -- but then, of course,
one doesn't have a default keyring, so you have to go back and list the
default keyring in the options file (or on the command line if you're
using no options).
Furthermore, in 1.0.6 and before, an imported key would be added to the
last ring in the list in the options file, so something like
would put the new key in the catch-all ring as expected with a simple
and then display all keys in the order listed when --list-keys was
specified. [Note that it actually wasn't a good idea to list the default
ring because it would be read twice, thereby confusing the trustdb, and
thus causing gpg to exit with an error code 2 even after a successful
verification, so I didn't use the first line above for long.] In 1.0.7,
however, in the absence of a default keyring, the imported key lands in
the *first* ring in the list, so everything was either landing in the
default ring with a
or in the foo ring with a
gpg --import --no-default-keyring
command; arrgh! The answer is to move the catch-all ring to the *top* of
the list as well as adding the default ring to the list and specifying
no-default-keyring, so the relevant section of the options file now looks
# I want to know what ring
# if you want keys to land anywhere else, you can't have a default
# keyrings to use (in search order)
### dumps into first one found(??)
and the only loss is that gpg --list-keys spits out all of the keys still
in keyring listing order (naturally) and so I can't easily see what has
fallen into the catch-all ring; I can make an alias for that easily
enough, even though it's a kludge.
How much of this behavior change was intended? I personally would much
rather see imported keys land in the last keyring in the options file or,
if there are any, the last ring specified on the command line; that makes
the most sense to me. Is anyone else using multiple keyrings and do you
have any input?
TIA & HAND
David T-G * It's easier to fight for one's principles
(play) email@example.com * than to live up to them. -- fortune cookie
http://www.justpickone.org/davidtg/ Shpx gur Pbzzhavpngvbaf Qrprapl Npg!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
-----END PGP SIGNATURE-----