Photo UIDs on --attribute-fd on Windows and strange LF->CRLF
dshaw at jabberwocky.com
Wed Aug 3 17:33:24 CEST 2005
On Wed, Aug 03, 2005 at 05:05:13PM +0200, Michael Schierl wrote:
> C:\temp>gpg --homedir \temp --status-fd 1 --attribute-fd 1 --list-keys
> JPEG >new.dat
> ********** cut here **********
> 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.
To make this work, you need to use a fd that isn't stdout, or
something like "--attribute-file new.dat"
Note in any case that the attribute is not a raw JPEG. You'll get the
attribute, which contains the JPEG.
More information about the Gnupg-devel