To reproduce:

The bug I'm reporting is that certain bad-formatted files can cause GPG to hang
in batch mode. It is my understanding that GPG should never hang waiting for
user input when in batch mode. It should process the file and either properly
decrypt or or terminate with an error. Since certain input can make it hang
instead, there is a bug.

The issue of the search returning the CAs as well as the certificates actually
searched for is now the separate Issue949.

Fixed in SVN for both versions (rev 4812). The batch generation will not be
fixed but I have documented that pitfall in doc/DETAILS.

Fixed in gnupg trunk (rev 4810). Will eventually make it into gnupg 1.4.

Interestingly, batch mode appears to detect the overflow. In that case,
overflows are silently rewritten to the creation timestamp plus one second:

Actually, the capabilities *are* listed with the secret keys, as long as you
provide a string to match against. The only case where they aren't listed is
when there's no matching string.

That is know. The capabilities are only listed with the public key.

I've tested this with gnupg and gnupg2, and both seem to behave this way.

Please describe exactly what you are doing. Refering to an outdated manual is
not really helpful to see what is going on. I degrade this to nobug for now as
it seems to be a support case; something we usually don't want to have in a bug
tracker.

BH,
if the error message is gone, maybe can you split out the other problem
from this issue.

I am running the ksh as weber (not root nor using sudo). I added the 'id'
command in the source code.. This is what I get back:

Are you running this as root (i.e. using sudo)? There is a known problem due to
this test:

/* There should be no way to get to this spot while still carrying
   setuid privs.  Just in case, bomb out if we are. */
if(getuid()!=geteuid())
  BUG();

If you really want to run it with effective uid of 0 you may change the test to

if (getuid () && getui () != geteuid ())
  BUG ();

However, this has to be done at several places (grep for geteuid).

Hi Werner,

Should eventually be implemented.

Okay. Removed from SVN trunk. For GnuPG 2.0.10 this option is obsolete and
fixed listing mode is used by default. It does not harm to use it, though. We
won't change it for 1.x.

A CRL DP is not required, although today most CAs provide one. For that reason,
dirmngr has a list of ldap servers to use as a fallback. For HTTP this is not
possible because there is no standard on the format for CRL http-URLs

Thanks for the information.

Right, there is a little bug. However, it needs some analysis before we can fix
it. The chain validation code is not easy to change.

What version of gpg did you used to crerate that file? I recall some problem
with zlib in the past. Thus if you encrypted a file using such a version of
zlib your data has been corrupted and there are no command line options to
recover the message. With a bit of hacking you could get to the decrypted but
compressed content, though.

Hi There !!!
My name is Tigran and I have some issue ...
On my system (Linux RH9 2.4.29) I'm using gpg (GnuPG) 1.2.1 with zlib-1.1.4-8.
But when I'm tring to decrypt files which was encrypted with public and private

keys it get me this error message:

gpg --decrypt-files /root/Test.xls.gpg
gpg: encrypted with 2048-bit ELG-E key, ID 80224B85, created 2005-02-11

"test1 <test@test.ru>"

File `/root/Test.xls' exists. Overwrite (y/N)? y
gpg: fatal: zlib inflate problem: invalid stored block lengths

secmem usage: 2048/3104 bytes in 4/7 blocks of pool 4544/16384

After this it creates a file Test.xls, but it has very small size and I can't
open it 'cause it's damaged.
I try to change my zlib with zlib 1.2.3 but it not help. Then I changed version
of GPG with GPG 1.4.9. But still I don't fix my issue.

The problem with the TP-robot and probably the alternatives is that it makes it
to easy for the translator. I have made the experience that the translators
just translate what's there without knowing the software they are translating.
And often without access to the source. That might work with standard software
but for software like GnuPG this can lead to a desaster. We have at times
debated over the English wording and thus the tranmslation of many things needs
thinking on how to express this. My hope is that without an automated system
the translators check there translation against the actual use of the strings
and perhaps ask if they don't understand. Some did this in the past and it
helped too clarify misunderstandings.

I sent the user a notice and asked him to check his work against the latest
gnupg version. However, the report is 3 years old and I don't know, if the user
will react. If hre does, I will forward the result to this item.

Right, email addresses are unique, but the key-email association is not unique.

No, it can't be. The exit status is not sufficient to convey all required
information. IF you want that you need to use gpgv along with a keyring of
trusted keys.

That one seems to be 1.4.1 which is completely outdated.

Applied. Thanks.

Applied. Thanks.

D61: 172_po_it_po.diff

this one is for trunk (same issues)

D57: 169_gnupg_2_po_de_po.diff

Email addresses on the Internet *are* unique. The option is too easy to misuse,
especially for a security program where selecting the correct recipient is
crucial. But, whatever. GNU.

Please read the man page:

I've since learned that this is actually the intended behavior. It's a dangerous
and bad default, and I urge you to change it to be something safer.

Since the error message is gone and searching in external keys works, this is no
longer urgent.

The error message is gone. However, the search result sometimes includes
additional certificates, not just the ones the user searched for. These are
then also imported, at least when using kleopatra.

That has been fixed a long time ago. Please check the quoted debian bug report.