Sorry, I can't replicate this:

dd9jn@vigenere:~$ HOME=/tmp gpg --verify --no-default-keyring --keyring

somekeyring.gpg --verify gpgol-1.0.0.tar.bz2.sig gpgol-1.0.0.tar.bz2

gpg: directory `/tmp/.gnupg' created
gpg: new configuration file `/tmp/.gnupg/gpg.conf' created
gpg: WARNING: options in `/tmp/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring `/tmp/.gnupg/somekeyring.gpg' created
gpg: Signature made Fri Jun 19 23:56:23 2009 CEST using RSA key ID 1CE0C630
gpg: Can't check signature: public key not found

or

$ gpg --verify --no-default-keyring --keyring somekeyring.gpg --verify

gpgol-1.0.0.tar.bz2.sig gpgol-1.0.0.tar.bz2

gpg: directory `/home/dd9jn/.gnupg' created
gpg: new configuration file `/home/dd9jn/.gnupg/gpg.conf' created
gpg: WARNING: options in `/home/dd9jn/.gnupg/gpg.conf' are not yet active

during this run

gpg: keyring `/home/dd9jn/.gnupg/somekeyring.gpg' created
gpg: Signature made Fri Jun 19 23:56:23 2009 CEST using RSA key ID 1CE0C630
gpg: Can't check signature: public key not found

Tested with gpg 1.4.8 and the current SVN versions of 1.4.x and 2.1.x.
All yield the same output.

Is $GNUPGHOME set? Can you run gpg with --debug 1024 so that we see the option
file used.

SVN and 2.1

It is reproducible here. But the result depends. First what you asked for:

gpg: NOTE: no default option file `/tmp/.gnupg/gpg.conf'
gpg: Signature made Thu Nov 12 19:51:04 2009 CET using DSA key ID E394D996
gpg: directory `/tmp/.gnupg' created
gpg: new configuration file `/tmp/.gnupg/gpg.conf' created
gpg: WARNING: options in `/tmp/.gnupg/gpg.conf' are not yet active during this run
gpg: fatal: /tmp/.gnupg: directory does not exist!
secmem usage: 1408/1408 bytes in 2/2 blocks of pool 1408/32768

What I see is that ou use the --verify switch twice in the commands(?).

I wasn't able to get the result you received using the --*keyring switches. I
simply did this: copied /etc/apt/trusted.gpg to /tmp and gave it reading
permissions for a user. Then I verified a Debian Release file:

LANG=C HOME=/tmp gpg --verify --debug 0x0400 --no-default-keyring \

--keyring /tmp/trusted.gpg \
--verify /var/lib/apt/lists/debian.wgdd.de_debian_dists_sid_Release.gpg \
/var/lib/apt/lists/debian.wgdd.de_debian_dists_sid_Release

Note, that the keyring in this case contains the key we ask for. The interesting
thing is, that if the keyring does *not* contain the key, it simply says:

gpg: NOTE: no default option file `/tmp/.gnupg/gpg.conf'
gpg: Signature made Thu Nov 12 19:51:04 2009 CET using DSA key ID E394D996
gpg: Can't check signature: public key not found
secmem usage: 1408/1408 bytes in 2/2 blocks of pool 1408/32768

It doesn't even try to create /tmp/.gnupg?

I can easily reproduce this issue. I will attach the strace.

In g10/tdbio.c the code is:

509 if( access( fname, F_OK ) ) {
510 try_make_homedir( fname );
511 log_fatal( _("%s: directory does not exist!\n"), fname );
512 }

I don't understand the logic here. You create the homedir and then you error out
with a message, that it does not exist. Is there simply a condition missing,
testing errno?

And the difference is made by the --no-default-keyring switch. Removing it from
the command makes it work too.

I don't understand the code either. I introduced it 10 years ago on Dec 4 when
I consolidated the make home directory logic. Obviously that code path was
never tested. The previous code called log_fatal only if the home directory
name did not end in ".gnupg". A simple fix would be to add another access test
after try_make_homedir.

I duplicated --verify due to a copy+paste error; it doesn't matter, though.

• g10/tdbio.c (revision 5221)

+++ g10/tdbio.c (working copy)
@@ -521,7 +521,8 @@

*p = 0;
if( access( fname, F_OK ) ) {
    try_make_homedir( fname );

• log_fatal( _("%s: directory does not exist!\n"), fname );

+ if (access (fname, F_OK ))
+ log_fatal (_("%s: directory does not exist!\n"), fname);

}
*p = save_slash;

This patch fixes it for me. The problem is the order in that the home directory
is created. Usually it is done while creating a new keyring. Due to
--no-default-keyring no keyring is created and thus when we need to check the
trust the code there creates the directory and failed. I am not sure why I was
not able to replicate it yesterday.

Will go in 2.0.14 to be released soon.

2.0.14 released thus closing.