Confirmed with different user accounts and window managers (KDE, stumpwm, ...).
The qt3 version works without problems.

Why do you include openssl and other stuff with -I ? Please show the config.log
file.

2.0.18 has been released and fixes this problem

cat(1) is not expecting any input thus you see the broke pipe from the first gpg(1).

Please direct such questions to a mailing list. This is a bug tracker and not a
support forum.

Please direct such questions to a mailing list. This is a bug trcker and not a
support forum.

Please direct such questions to a mailing list. This is a bug trcker and not a
support forum.

I tested this patch, and it does in fact change the behavior as requested.

Running gpg on the file directly:

Can you give me an example of how to call gpgtar? From the incomplete details
output of kleopatra and gpgtar --help
I've put together:
C:\>"\Program Files\GNU\GnuPG\gpgtar.exe" -e --openpgp --skip-crypto --output
test.tar.gpg c:\Users\intevation\Desktop\test_bad

Can you please try to do this from the command line?

Duplicate of T1324

Sorry, after creating this i've noticed that this is a duplicate of issue:
T1324

I think this is fine. I originally wrote the code to send short keyids as pksd
couldn't properly handle long keyids or fingerprints. As pksd is now dead, and
sks properly handles this, I think it is reasonable to send the longest ID
appropriate (send fingerprints if we have them, long keyids if we have them, and
short keyids if we must).

Backported fixes to 1.4. g10/sign.c was not an issue there.

David, what do you think about sending long keyids to the keyservers?

D149: 332_1340.diff

Attached is a proposed patch that should permit passing long keyIDs or full
fingerprints to the keyservers.

Given that the referenced draft was written in 2003, we now have 8 years of
documented expectations that keyservers can do this. The dominant keyserver
implementation today (SKS) can handle this with no trouble.

It may be that these days keyservers can cope with long keyids. However old
keyservers are not able to do that.

this is not a limitation of the keyservers; gpg itself is stripping all but the
short keyid. adding "--keyserver-options debug" to the command shows that in
every case, gpg is requesting the following URL:

Libgcrypt does not support 64 bit Windows yet. In particular do not use it even
if it would build and run fine. MSVC is not a supported build platform anyway.

Also changed for 2.0 - will go into 2.0.18.
Also changed for 1.4.

All implemented for 2.1.

concerning the prompt: would it be possible to look up and display the key name
from id_rsa.pub, either at ssh-add time or at confirm time? i might remember
remote host fingerprints, but locally, those names are the best description.

Good idea. I started to implement it for 2.1. Tehre will be flag in the
sshcontrol file named "confirm". Need to compute the ssh fingerprint to
resemble the prompt ssh-agent prints (internally we use our keygrip style
fingerprints).

You asked a question. Please don't do this in the bug tracker but use a mailing
list. See http://gnupg.org for a list of mailing lists.

Fixed in master.

Okay, I'll add a note to the option.

If this behavior is by design, could at least documentation (man page or
/usr/share/doc) be updated to say so? Some notice in either (or both)
--with-colons and --keyid-format entry saying that --keyid-format (and possibly
others) will be ignored when --with-colons is used.

That is not a bug. --with-colons is the machine interface and it does not
return abbreviated information as the human readable output does.

See also my comment in issue#1353.

Duplicate of T1353

Here is the link for people landing here from a search engine:
http://git.gnupg.org/cgi-bin/gitweb.cgi?
p=gnupg.git;a=blobdiff;f=g10/pkglue.c;h=3a078bd3fe39a85ced37b5430a6e0c76f2a41be7;h
p=05f7167c2e8c56beab207f58626bbd3b293bad3b;hb=328ac58962ac9842e1e0c21c9ad12182f0d9
bed6;hpb=070df4ea58d30a9ef4e86d242ed696a25adbe214

Indeed and I was pretty sure it was related to that...I even tried downgrading
gnupg and it didn't work...
Thanks for letting me know.

Are you using the new Libgcrypt 1.5.0? This is a known problem. Fix is in git
commit 13290b0e0

I will shortly release 2.0.18 to address this problem.

Thanks for the answer.
What is the solution right now?
Not use libgcrypt 1.5.0 with GnuPG <= 2.0.17?
Or patch GnuPG?

That's known. GnuPG devel has already been fixed in git (328ac58).