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

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.

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.

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

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.

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

In will include estream.h.

Works for me, thanks.

The fix applied is a pth_kill wrapper and to protect all pth calls in estream.c.
Please try ce98524.

I've now switched from gcc4.3 to gcc4.4, and this warning is no longer emitted.

Quoting my gnupg-devel mail:

D147: 331_gnupg-2.0.17-Do-not-lock-the-es_list-when-flushing-it-from-es_dei.patch

cf. Fabian Keil's mail from today to gnupg-devel.

That is a limitation of the keyservers.

We allwo only algorithms which are implemented. IDEA is not implemented because
it is patented. MD5 is implemented but too weak to be used. We won't allow that.