If a system call blocks we are doomed to wait. We use a user land threads
implementation (Pth) and wrap most system calls so that we can handle the
blocking. However we can't do that for all system calls. We can wrap some of
them but only as long as a select can be used to wait for the system call.

Hmm thinking about this, it is almost like a denail of service attack, because
dirmngr will block other clients.

That must be a problem of the FreeBSD ports. GnupG comes with a man page. On
my system I can do

man gpg

for th1 1.4 GnuPG and

man gpg2

for the 2.x gpg. Please report to freebsd.

FreeBSD 8.1 release :

man gpg

No manual entry for gpg

A 2.0.17 will be released soon.

oops. Website fixed. The branch names are
STABLE-BRANCH-2-0
STABLE-BRANCH-1-4
Note the dashs. We don't use a dot because the names date back to CVS and that
does not allow a dot in the name.

From http://gnupg.org/download/cvs_access.en.html:
the stable 2.0 version (currently version 2.0.16) is known as STABLE-BRANCH-2.0;
the stable 1.4 version of GnuPG (1.4.11) is known under as STABLE-BRANCH-2.0.
I guess I should look at the first of the two :)

Huh? "man gpg" "man gpgsm" "man gpg-agent" ... all work perfectly for me.
For ages.

GPG needs to to run trial decryptions with all available secret keys; there is
no specific order for this. This can be improved by ordering the packets so
that those with known keys are tried first and only then the wildcard keys. The
wildcards could also be more optimized. This is a actually long standing wish
by myself but I didn't found the time to implement it. Instead I implemented
the --skip-hidden-recipients in 2.1.

g10/sign.c: Pretty obvious error. Not a really problem because DSA
key sizes must be multiples of 8 bytes.

This is just a warning.

Please explain in more detail what you are doing. And well we don't have
support for Windows7 yet. According to user reports it seems to work but we
don't have first-hand knowledge. Windows7 hardware arrived only recently.

Please ask on the ML for advise.

STABLE-BRANCH-2-0 344d72b
has the fix. Patch below.

STABLE-BRANCH-2-0 344d72b
has the fix.

Sounds good. I'll test it as soon as we have a kk package for the next release.

Duplicate of T1203

This looks pretty much like T1311.

Please don't attach files in a more or less proprietary format. We will only
accept plain text files. Further the bug description should be a message and
not an attached file. File may be attached for test data or if you want to
provide long log data.

You are right, that is faulty. The correct code is:

Please don't put bugs into the BTS for a development version. Use the
gnupg-devel@ mailing list instead.

Of course GPG_TTY is set properly in both xterm sessions

Already fixed in git master.

Fixed in 3a7058c

Please write a proper error report or ask for advise on a mailing list.
Do not upload files in a proprietary format (doc); we will only look at plain
text bug reports. see http://bugs.gnupg.org

NOTE file contains data restricted by HIPPA.

D146: 322_gpgme-list-end-doc.patch

D145: 321_gnupg-2.0.16-review-fixes.patch

Fixed in dirmngr and also in GnuPG trunk. Patch for gpg4win created.

I did some more research (I think I can localize the GPG code where the problem
happens, and currently I conclude that it is really a Windows bug) and wrote up
my findings in the attached file GnuPGRenamingBug.rtf, from where you can
download everything and print it out.

AC_PATH_TOOL will fall back to gpg-error-config, so the default behavior is
unchanged. AC_PATH_PROG however will wrongly select the host's gpg-error-config
which breaks cross-compiling. it isnt up to random packages to manage the HOST
prefixed tools, so the gpg-error package not explicitly installing it is
irrelevant. cross-build systems take care of creating the wrappers automatically.

additional information:
gpg4win (2.1) is installed on a Microsoft Windows 7 Client