No response to my last message. It seems to be an IPC bug and not related to
GPG given that other GUIs don't have these problems.

A quick guess: Can you please put an

We should address this in 1.6

We will address this in 1.6. At least for ELF systems supporting the weak
pragma and for W32.

Both done.

Tested with current gnupg and pinentry-qt4:

pinentry qt4 (git 5190773293bc38550bbc8aeb1b539bfb47a47c78)
qt 4.7 
gpg (GnuPG) 2.1.0-git328ac58
libgcrypt 1.5.0-gitb90be28

gpg does several stept. Decryption may succeed but uncompressing may fail or
signature verification may fail. Or there is some extra data appended which gpg
tries to process but fails.

Can someone tell me how I can get "invalid packet messages", followed by "decryption ok", ending in a
return code 2 and still produce a file I can find no issues with?

I've just noticed that I'm even getting some warnings about invalid packets on a SHA1 digest file - a 660
byte PGP file, which produces an EBCDIC 40 byte SHA1 digest file.

Hi Werner,

The file or parts of the file are corrupted. I suggest that you check with ASPG
(the vendor of megacryption) to see what's going on. My guess is a conversion
problem (fixed record size, LD, CR, whatever).

Patch resolved nothing.

Hi,
I just created 10 new keys, and only one was added correctly to the agent. I
enountered a variety of bad behaviour.

If a recipient has more than one key - for instance outdated keys, needed for
decryption of older messages, it is sometimes difficult or impossible to make a
mail application encrypt with the correct key. Recently I fought this one, and
got around the problem in both KMail and Thunderbird by demoting the Trust
status of the older key, but although this works it's not ideal for the
following reason.

The exit code alone is not sufficient to return a useful error status. Thus
Marcus is right that we can't do much and gpgconf should be used to validate the
configuration.

I am closing this bug because there was no answer to my request for a more
detailed report.

I reassign this to gnupg, because this does not seem to be related to gpgme at
all. Maybe it can be closed due to age, don't know.

I merged in the translation to the gnupg package, where dirmngr now resides.

Fixed in repository.

In this case it is a bug in poldi. Reassigning.

Dirmngr 2.1.0-gitde7cfc0 also stays active.

Testing the fix:

So, I understand this can't be fixed in software?

There is no cache for smartcards; depending on the type of smartcard they
remember their PIN until they are powered down. With the OpenPGP card you may
use the gpg forcesig subcommand to force a PIN entry for each use of the
signature key.

Oh well, the svn syncing stopped quite some time ago. Just renabled it and 347
should no be on cvs.gnupg.org

The repository contains outdated translations. Before releasing gnupg-2.0.17, I
had been poked by Werner and I have sent updated translation of gnupg2 back.
It's part of 2.0.17 release. You must have stored current translation somewhere
else.

Please use a wrapper for this. The problem with an --language option is how
should we display messages pertaining to option parsing if we don't have the
languages already set. This might lead to a mixup of languages which for sure
will yeild in complains by other users.

Stored files can be in any encoding, as they are not displayed, so
interpretation is up to the user. But for a displayed string, the encoding matters.

Fixed today, thanks.

Fixed today, thanks.

Seems to be fixed in gpg4win 2.1.0

Clearly gpgsm outputs to stdout and gpgconf is confused by that.

There is a configure check now. I am still not happy that we sleep at all, but
thats a bigger issue.

I merged it into gnupg where dirmngr now resides. The cs.po file there is
probably out of date anyway though and may need some massaging.

Werner, where is the patch for dirmngr 1.1.0?
http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/?root=Dirmngr only goes up to rev346,
while you say rev347 has the fix. Maybe a missing sync on the svn repositories
on your part?

I can not reproduce this on Snow Leopard, I guess it has been fixed in the meantime.

Haven't had a chance to test it, I was somehow waiting for a new release.
Just made sure I get a 1.1.0 patched package to test next.