Might be a zlib problem; see also T1011 .

Change 5028 for 2.0.

JFTR: I have only tested on an amd64 box. But I can check this later with an
i386 box too.

I see this then:

This has been fixed in the SVN:

D79: 225_fix.diff

Even with the example file inthe Debina BTS, I can't replicate it with 1.4.8,
1.4.9. the current 1.4 svn version or gpg2. It is either a problem of libz or
more likely due to the amd64 CPUI. Unfortunately I don't have such a box
running right now.

See the recent threads on gnupg-devel for a discussion on this topic.

Change 5024 for 1.4. Will do 2.0 shortly.

I have not checked the code, but it seems plausible not to check the subkeys
once the primery key has been marked as expired. Checking the subkeys would
spend useless CPU cycles.

Interestingly enough, it's no longer the default in libcurl. We'll have to do
it for both the libcurl and emulation cases.

I think that if the primary key is expired, the subkeys should be treated as
expired as well. The only thing that makes the subkey valid in the first place
is the binding signature - which was issued by the expired primary key.

This is the occasionally-requested "--unwrap" command which would stop
processing after a single layer of the file. I.e. convert Enc(Sign(data)) to
Sign(data).

Fixed in svn rev 5021. Will be fixed for trunk as well. Patch attached.

D88: 224_bug1058-fix.diff

Does LDAP find these keys if they are C-style escaped? I guess that depends how
they have been put into the LDAP DB.

Ah, never mind. I found a key (ACCFFAE2) that nicely duplicates the problem.

Could you attach a copy of the public key you're having a problem with to this
bug? If you don't want to reveal that key for whatever reason, could you
generate another one with the 'é' character that shows the same problem?

I'm using Debian GNU/Linux 5.0 and most of the PGP Keys have been created with
Enigmail (the Mozilla Thunderbird extension).

Fixed in svn rev 5019 for gpg1 and gpg2.

What OS are you using? In general there is no need to use --charset; however
it is not related to the problem.

My fault, thanks. Fixed in rev 5016.

Thanks, that did it.

D87: 223_default-preference-list-change.diff

This is not a bug. For support please see http://gnupg.org/service.html .

Vendor is using Gnu Privacy Guard,which uses OpenPGP to encrypt the files and
we are at gpg (GnuPG) 1.2.6 version
We are receiving the error gpg: [don't know]: invalid packet (ctb=14) once in
a while.It doesnot happens for all the files.

Thanks for the report, I removed the dead entry. allow-pka-lookup was changed
into a verify option quite a while ago. Fixed in rev 5010:

Right, that was missing.

The right way to delete an option is:

The options --batch or --no-tty will help you.

Forget the second part. It prints this message only, if it indeed needs input
and giving --yes works in this case too. So there was a fault on my side.

Maybe we misunderstood(?). The gpg-agent is not used.

I don't want to decided whether thisis a bug. The thing is that using gpg with
gpg-agent is more of a temporary solution than something we want to work as
clean as possible. For such use cases it is better to use gpg2.

Don't put too much weight into gpg's exit codes ;-)

I need to check the first case.

Fixed in svn rev 5005. (gpg1 and gpg2)

It is basically the same code as used in gpg2. On a GNU system tty_get_ttyname
always returns "/dev/tty". This is used as a fallback solution so that we can
tell gpg-agent at least one tty which may work.