Multiple keyring support

[rabbito@san.rr.com]

On Wed, May 15, 2002 at 10:55:49AM -0500, David T-G wrote:
> Hi, all --
> 
> ...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
> 
>   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
>   
>   #
>   # if you want keys to land anywhere else, you can't have a default
>   #
>   no-default-keyring
>   
>   #
>   # 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?

Hi,

    I was just looking through the archives because I was interested in
having multiple keyrings.  It seems like a loss of functionality came
about from 1.0.6 to 1.0.7+.  Was this intentional?  Is there another way
to:

    - have default imports and verifies dump the keys in to a default 
      catch all keyring.

    - be able to override (on the command line) default imports and
      verifies into a specific keyring file.

    - override the keyring to use on the command line.

    - list the contents of the pubring.gpg first when using --list-keys

It seems like 1.0.6 did all of this, but with 1.0.7+ it's not possible
(once you setup the options file as above, you can't get back to the
pubring.gpg file by using the --keyring pubring.gpg on the command
line).  If there is a way to do all of these, please let me know.  Thank
you.

-- 
Rabbito