Taking a look at the code, it would require to adjust

Fixed in SVN 5253. Thanks.

D120: 277_gnupg1.texi.diff

Patch attached.

May I ask for the status? Seems, there were no objections.

Agreed.

Well, should be implemented.

2.0.14 released thus closing.

2.0.14 has been released - closing.

Thanks. Applied to SVN.

Fixed in all branches. rev. 5236. Patch for 1.4.10 below:

I don't think it is wise to change results returned from the backend engine too
much in GPGME. It makes it more confusing to see what's going on by giving
different results for essentially the same operation.

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.

• 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;

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.

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

In g10/tdbio.c the code is:

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

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

Sorry, I can't replicate this:

Sorry, you already fixed this. Closing myself.

I don't think this is a proper solution. --default-key has the same problem as
--local-user. What we can do is to fail if a key has been specified in a
non-unique way. Selecting one by chance is a Bad Thing.

These bug reports are sometimes mixing two different issues: The
debian-keyring and r/o keyrings for other purposes.

D107: 253_typo_adresses.diff

There is further an "it's" which must be "its". Patch attached.

D108: 252_its_typo.diff

D103: 251_gnupg_2_spell.diff

Patch for 2.

D104: 250_gnupg_2_spell.diff

Patch for 1.4.

D105: 249_gnupg_1_4_spell.diff

Wen can look into this during the development of 2.1.

We will do this in 2.1 and maybe backport it later

We need to review the purpose of gpgkey2ssh. It might be easier to integrate
this into one of the other tools.