Hm. Comparing --debug-all on both architectures I see clear differences. Not
sure if they count. But the value for length on the amd64 box, when it re-enters
the loop looks weired:

i386: no loop

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:

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.

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

Fixed in svn rev 5019 for gpg1 and 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.

Since svn rev 5003, the warning is only printed if option --verbose is used.
That may be helpful for some users and does not complicate things too much.

Asking to create a revocation certificate is a good idea. Frontends can make
this the default then. However, this is something for GnuPG-2 and not for the
standalone version. I expect people using the standalone version to be smart
enough to create one. Should be discussed on gnupg-devel.

IIRC, the sematics of sign are too complicated for --multifile. If the problem
is just to avoid entering a passphrase several times, gpg-agent is very helpful
and solves the problem nicely.

Using multiple keyserver might be a usable thing but with the current
infrastructure it is not easy to implement.

This has been discussed several times on the mailing lists. You can't do that
because gpg needs to ask several questions. There are too many choices for a
command line mode. --sign-key makes it only easier in the most common cases. A
--force option won't help because you don't know which user ID you are going to
sign.

Right, there is a nasty memory leak. It took me at least 6 hours to import an
8.5MB keyring. After the fix I was able to import the same keyring in 18
minutes including the trustdb check. Find attached a patch against 1.4.9 which
should also work against 1.4.7 and with slight adjustments for older versions.
It does work with GnuPG-2 as well.

D84: 219_gnupg-bug1034.diff

When I checked for a force-yes switch, I grepped for "force" and missed the
--yes switch. But also using this switch results in a prompt, so the main issue
persists.

Okay, fixed in SVN 4958.

From the the glibc manual (24.7.3 Process Signal Mask):

I can't replicate it with a card initialized the standard way and revoking the
encryption key. Will test later with only the subkey on the card. This is
using gpg2 or gpg-1.4.9 along with scdaemon.

Given the proposed workaround, I'd say we don't fix that.

Applied to 1.4 and 2.0, svn 4843.