Photo UIDs on --attribute-fd on Windows and strange LF->CRLF conversions

Adam Schreiber sadam at CLEMSON.EDU
Wed Aug 3 18:40:55 CEST 2005

Hash: SHA1

David Shaw wrote:
>>When trying to find the original image from the new.dat file, it seems
>>that  every 0x0a byte (line feed) inside the image is mangled to a 0x0d
>>0x0a. The length mentioned in the "ATTRIBUTES" line mentiones the
>>decoded length. So decoding is a bit tricky, especially since when you
>>read a 0x0d as last byte, you do not know whether to stop (i. e. it was
>>a 0x0d byte) or not (if a 0x0a byte follows, it has been a 0x0a byte).
> The problem here is twofold - first, you can't dump jpegs that way.
> You'll end up with garbage because it'll be mixed up with the key
> listings themselves.  The second problem is related to the first -
> you're dumping to stdout, and stdout on windows does textmode
> conversion by default.

I've been working on Photo ID support for seahorse.  We decided to
attack the problem by using a helper program to output a jpg to a known
location.  Since gpg uses xloadimage on UNIX systems to display the
photo ids, we created a program that dumps the intended output for
xloadimage to a file specified by an environment variable.  We're using
gpgme_op_edit to trigger the output, but you could do a similar thing
with the command:

gpg --edit-key <keyid> uid <uid> showphoto quit

The helper program can be found in cvs at

The other glue can be found in the latest patch attached to GNOME
bugzilla bug #160413

Specifically look at the changes in src/seahorse-key-op.c for the gpgme

Adam Schreiber

- --
Why isn't all of your email protected?
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -


More information about the Gnupg-devel mailing list