Tested System was Debian Lenny, XEN Instance.
Used command was

gpg2 -b testfile.txt

Fixed but not tested with commit 6daa9db; to be released in 1.4.12.

Thanks for the update. WIth this info on record I will close this bug.

Thanks, Werner, for your reply and your suggestions. I'll have a look at the
GPGME solution.

Wint 2.1 the protect-tools has been dropped. Thus we won't fix it in 2.0.

Note: T1190 is a bug report regarding this.

See also T1109 which describes the problem in a few words.

Duplicate of T1109

Hi Werner,

We had some other reports on the ML about similar problems. Really time to go
after it.

This is a long standing problem. Usually GPG is used by other utilities and
they exepct utf-8. Thus we would habe to detect the plain use of the console
and then dosomething about it.

Still missing in 2.0.17; should we fix it at all in 2.0 or do it only in 2.1
(which has a lot of changes in the keyserver area).

I believe we tracked it down to the sending machine (an IBM mainframe) writing the encrypted
bytestream out to a FB (Fixed Blocked) dataset. This results in the PGP datastream being padded
out to a specific width as defined in the DCB. When gpg tries to decrypt this, it finds these
padding bytes and all hell breaks loose with a variety of different errors.

If gcc's print format checks would only support custom format string extesions
we could easily implement a filename specifier. Without that we are not able to
use format string checks which is something I don't want to miss.

It seems this is not important enough to implement an extra filter for this case.

I you don't have any further information I'd like to close this bug.

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.