Yep,
already fixed everything on my boxes.

Fixed in SVN 5253. Thanks.

I am sorry about this. Please read
http://lists.gnupg.org/pipermail/gnupg-users/2010-January/038045.html

That's not a GnuPG problem but rather Microsoft's backup funcitionality.

D120: 277_gnupg1.texi.diff

Patch attached.

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

Agreed.

Good catch. Tanks.

Thanks for the excellent description.

I tracked it down with GPG (hadn't used that in 10 years).

That is a long list of comments with unclear error sepcification. I can't find
anything which explains why this is an nuPG problem. I'd appreciate if you can
summarize the problems and possible sulutions from theat forum right here in the
BTS. Thanks.

To tarck this down I would also need the key. Can you create such a broken
message using one of the example keys (e.g. alfa@example.net)? IF so, feel free
to send it to me directly wk@gnupg.org - if the data is kind of sensitive, feeel
free to encrypt. Due to anti-spam meastures it is best to send a gzipped
tarball or any other gzipped data; or send me an URL.

What is the content of tests/openpgp/conventional.test.log ?

Well, should be implemented.

2.0.14 released thus closing.

2.0.14 has been released - closing.

We can't do anything about it.
Cards with manufacturer id 5 and serial numbers up to 346 (0x15a) are affected.
Newer cards work fine.

Thanks. Applied to SVN.

Fixed in 2.0 and 2.1 rev 5238.

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

Done in trunk (2.1), rev 5233

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.

Implemented for dirmngr. That will go into dirmngr 1.1.0.

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.

Commited to 2.0 and trunk, rev. 5224.
Now for dirmngr.

Okay, I implemented that for gpgsm:

That is a hard to fix problem. We don't have the infrastructure to merge
keyserver requests. Adding this to gpg will be quite some work. A tentative
plan to implement this would require a local daemon to cache requests (e.g.
enhancing dirmngr) and to rework gpg to allow for asynchronous updates.

Dear Mr. Koch,

From my investigation the only workaround seems to be the no-honor-keyserver-url
option. What I could imagine is, to test, if the given keyserver pref of a key
is equal to the specified preferred keyserver and delay this key processing and
process it with all other keys without keyserver prefs. However this won't solve
the problem completely, as all other keys would still be processed one after the
other (which BTW sounds reasonable to me).