Okay, fixed in master commit ea9df94. Goes into 2.1 Thanks.

Now problem got even worse. My 2.0.18 agent can not unlock my old SSH keys, nor
can it add new SSH keys.

A test program compiled with MinGW under Windows gives the same result - CP866.
I used just 'gcc console.c' and ran a.exe in MinGW Shell.

I copied some text output from console to Notepad.exe (standard Windows program).
Look first line in gpg-consoleoutput-unicode.txt

Rather strange error:

According to libiconv documentation, it recognizes CP866 as legal charset name.
http://www.gnu.org/s/libiconv/

Ok, I wrote a small test program in Visual C:

We use what the system tells us. See jnlib/utf8conv.c:set_native_charset . An
alias for CP866 might be missing. We don't switch the console charset but use
libiconv to translate between charsets.

I wrote a small test program for .Net to see what is console charset:

But why is it unreadable? I see Cyrillic letters (gpgconsole.jpg) but this is
not Russian text!

We always output plain UTF-8 on Windows.

We don't have any plans for a new release.

Can i get an update on where this patch stands? I'm concerned that people are
actively sniffing around the idea of crafting duplicate short keyids:

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

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?

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:

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).

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.

Fixed but not tested with commit 6daa9db; to be released in 1.4.12.

Thanks for the update. WIth this info on record I will close this bug.

Thanks, Werner, for your reply and your suggestions. I'll have a look at the
GPGME solution.