Keys listed twice when --keyring used - request to filter

[Kurt Fitzner]

I was probably unclear.  I didn't mean for changes for GPGME, but for
GnuPG itself.

Any --keyring command given on the GnuPG command line causes GnuPG to
consider another keyring, irrespective of whether or not that keyring
has already been considered for other reasons.  For internal handling,
this makes no difference, other than the fact GnuPG might take a few
more milliseconds to complete a command.  But when, for example, you ask
GnuPG to list keys, then GnuPG will happily list all the keys from its
default keyring, and then from any other keyring specified on the
command line, even if it has already listed them before.

What I am asking is that, when listing keys, GnuPG keep a simple talley
of keyrings it has listed before and not list them twice.

Marcus Brinkmann wrote:
> At Tue, 06 Sep 2005 05:21:51 -0600,
> Kurt Fitzner <kfitzner at excelcia.org> wrote:
> 
>>The GPGME library has no command to return the name of the keyrings that
>>GnuPG is using by default.

I am actually using Timo's Windows port (MyGPGME).  I patched this to
support feeding in keyrings at the request of GPGee users who keep
additional keys on removeable media.

> In fact, gpg doesn't have a way to return the name of the keyrings
> that it is using by default.  You have to figure it out from the
> configuration file.  I haven't checked it out, but those filenames
> could even be relative instead of absolute, adding another complication.

This is pretty much my point.  Because it is impossible to know without
parsing the options file (something I'm not about to get into for my
little front end), it's impossible to know whether the user has supplied
my front end with a keyring file that is already the default one so that
I know not to feed that keyring file to GnuPG.

> It is our opinion that keyring settings are a crypto engine
> configuration that should be done in gpg.conf (thus setting it for all
> applications).  If you need total control over the crypto backend, you
> can from 1.1.x on create a separate .gnupg home directory and activate
> it on a per-gpgme context (or per application) with
> gpgme_set_engine_info.

While not totally relevant to this discussion (on whether GnuPG should
filter multiple keyring files in user output), I should go on record
that I don't agree with this assessment.

There are many times that a front-end may want to deal with keys coming
from alternative keyrings.  Keys on USB-dongle-devices and other
removable media, for example.  A friend comes over and his keyring is on
a USB device.  I shouldn't have to adjust the "crypto back end" - the
GnuPG options file in this case - if I want to temporarily add it.  My
feeling, and the reason why I patched --keyring support into Timo's
MyGPGME library in the first place, is that the front end should be able
to tell GnuPG to do whatever it is the user wants.

To require the user to modify the GnuPG options is placing a heavy
burden on front-end developers who want to provide the user with the
ability to access keyrings on a temporary basis.

	Kurt.