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

Tested System was Debian Lenny, XEN Instance.
Used command was

gpg2 -b testfile.txt

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.

Wint 2.1 the protect-tools has been dropped. Thus we won't fix it in 2.0.

Note: T1190 is a bug report regarding this.

See also T1109 which describes the problem in a few words.

Duplicate of T1109

Hi Werner,

We had some other reports on the ML about similar problems. Really time to go
after it.

This is a long standing problem. Usually GPG is used by other utilities and
they exepct utf-8. Thus we would habe to detect the plain use of the console
and then dosomething about it.

Still missing in 2.0.17; should we fix it at all in 2.0 or do it only in 2.1
(which has a lot of changes in the keyserver area).

I believe we tracked it down to the sending machine (an IBM mainframe) writing the encrypted
bytestream out to a FB (Fixed Blocked) dataset. This results in the PGP datastream being padded
out to a specific width as defined in the DCB. When gpg tries to decrypt this, it finds these
padding bytes and all hell breaks loose with a variety of different errors.

If gcc's print format checks would only support custom format string extesions
we could easily implement a filename specifier. Without that we are not able to
use format string checks which is something I don't want to miss.

It seems this is not important enough to implement an extra filter for this case.

I you don't have any further information I'd like to close this bug.