Although it is an application error to assume a certain sigprocmask beyond
what's defined by POSIX, we should be nice and try to kill pth too.

Ah found something:

Fixed in my working copy. Thanks.

Right, I did no "make dist" to check this. Fix committed.

No, that is not a typo. --daemon used to be required to avoid starting several
gpg-agents - which happened quite often while in lets-see-what-happens testing
mode. Later the code was change so that running gpg-agent without any args
tested whether a gpg-agent is already running. Thus we can simplify the paragraph.

You are keeping me pretty busy :-)

kbxutil is more a debug tool and may change at any time. I don't think that a
man page is useful.

Applied to both versions (r5030). Thanks to you and also to Jens Seidel.

See these threads for example:

The internals are already set for multiple keyservers (opt.keyserver is a
strlist, etc.) I had to implement it for the auto-key-retrieve feature, which
does support multiple servers.

D92: 231_314068_gnupg1_de.diff

D93: 230_314068_gnupg2_de.diff

I get a build failure. g10/gpgv.c probably misses:

And the same fixes for gnupg 1.4.

D94: 229_~_packages_vcs_gnupg_2_314068_gnupg2_de.diff

D95: 228_314068_gnupg2_de.diff

I found some more. So here a new diff for gnupg 2.

One more. At

I see. Then comparing the value to ULONG_MAX should solve the issue, right?

Found the cuplrit:

Well that value is 0xFFFFFFFFFFFFFFFF.

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.