gpg --gen-key keyring behaviour

David Shaw dshaw at
Sat May 24 05:54:01 CEST 2003

Hash: SHA1

On Fri, May 23, 2003 at 07:45:59PM +1000, zem wrote:
> The Unix version of GnuPG 1.2.1 appears to ignore the 
> --no-default-keyring and --keyring directives when generating a key.  
> '--secret-keyring' seems to work, but the public key is written to the 
> default keyring, rather than the one specified on the command line - at 
> least in the case where the specified public keyring does not yet 
> exist:
> $ gpg --no-default-keyring --secret-keyring test.sec --keyring 
> -vv --gen-key
> [...]
> gpg: keyring `/home/zem/.gnupg/test.sec' created
> gpg: keyblock resource `/home/zem/.gnupg/': file open error
> [...]
> gpg: writing public key to `/home/zem/.gnupg/pubring.gpg'
> gpg: writing secret key to `/home/zem/.gnupg/test.sec'
> I get similar results in batch keygen mode, whether or not I use the 
> '%pubring' and '%secring' directives.
> Is this a bug or a feature?  Am I missing something?

Hmm.  Are you sure you are using 1.2.1 ?  If so, do you have a
"keyring xxx" line in your gpg.conf file?  GnuPG will only create a
new keyring if it is the first ring specified.

> Also, I think I've discovered a bug in batch mode key generation with 
> the win32 client 1.2.2.  If I specify a secret keyring with '%secring', 
> --gen-key overwrites existing keys in that keyring.  Removing the 
> '%pubring' and '%secring' directives and using '--no-default-keyring', 
> '--keyring' and '--secret-keyring' instead, fixes the problem - the 
> win32 client doesn't ignore these.

This one is not a bug, it's a feature.  %pubring and %secring are used
to write the key into a new set of keyring files, and so are
documented (in doc/DETAILS) to overwrite.  As you have discovered, if
that is not the behavior you want, you can use --keyring and
- --secret-keyring to append the new key to a file.

Version: GnuPG v1.2.3-cvs (GNU/Linux)


More information about the Gnupg-devel mailing list