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

[David Shaw]

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.

David