keyrings and moving keys

[David T-G]

--11Y7aswkeuHtSBEs
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi, all --

=2E..and then David T-G said...
%=20
% 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

  keyring pubring.gpg
  keyring pubring.foo.gpg
  ...
  keyring pubring.catch-all-keys.gpg

would put the new key in the catch-all ring as expected with a simple

  gpg --import

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

  gpg --import

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
like

  #
  # I want to know what ring
  #
  show-keyring
 =20
  #
  # if you want keys to land anywhere else, you can't have a default
  #
  no-default-keyring
 =20
  #
  # keyrings to use (in search order)
  ### dumps into first one found(??)
  #
  keyring pubring.catch-all-keys.gpg
  keyring pubring.gpg
  keyring pubring.foo.gpg
  ...

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

:-D
--=20
David T-G                      * It's easier to fight for one's principles
(play) davidtg@justpickone.org * than to live up to them. -- fortune cookie
(work) davidtgwork@justpickone.org
http://www.justpickone.org/davidtg/    Shpx gur Pbzzhavpngvbaf Qrprapl Npg!


--11Y7aswkeuHtSBEs
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE84oUFGb7uCXufRwARAlq/AKCdySOv6hcvRoCvybTBPkr3ea9fEwCghkKq
cRAW1ur2lNb+tfLaA839FOM=
=4Uek
-----END PGP SIGNATURE-----

--11Y7aswkeuHtSBEs--