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

[Michael Schierl]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[this is a resend of a message from 2005-08-02 00:29 since that one
apparently did not get through...]

Hi,

i have a "problem" with photo uids:

************* cut here *********

C:\temp>gpg --homedir \temp --edit-key JPEG
gpg (GnuPG) 1.4.2; Copyright (C) 2005 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.

Secret key is available.

pub  1024D/835DE7D3  created: 2005-08-01  expires: never       usage: CS
                     trust: ultimate      validity: ultimate
sub  1024g/023605A9  created: 2005-08-01  expires: never       usage: E
[ultimate] (1). JPEG Test <jpeg at test.invalid>

Command> addphoto

[...]
Enter JPEG filename for photo ID: c:\temp\1px.jpg
Is this photo correct (y/N/q)? y

You need a passphrase to unlock the secret key for
user: "JPEG Test <jpeg at test.invalid>"
1024-bit DSA key, ID 835DE7D3, created 2005-08-01


pub  1024D/835DE7D3  created: 2005-08-01  expires: never       usage: CS
                     trust: ultimate      validity: ultimate
sub  1024g/023605A9  created: 2005-08-01  expires: never       usage: E
[ultimate] (1). JPEG Test <jpeg at test.invalid>
[ unknown] (2)  [jpeg image of size 634]

Command> q
Save changes? (y/N) y

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

If this is intentional, it should be documented somewhere, and there
should be some way for the client program to detect this (so that the
same program works on Windows and on other OSes). But IMHO it should be
simply fixed (no LF->CRLF in binary data).

(JFTR: The exactly same effect appears when I do this by creating a new
process (from Java) and reading its stdout - so it is not some odd
conversion done by the shell.)

Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQEVAwUBQvDdKZ2HdZ9YtIzdAQLlJwgAj3a1KXPlr3Bs0+Jap7z+MlsPiv0z4u/d
YbCZ0KDSeCNoSKEwTRhTcx2MAcoDIvFV+ZnBaLLSehhTOjRIjyL2ur/A5Smpd3if
B0MRpNRfjXuiWzCUxpZEhcrAvTj32KmfuFiB1wHHeL8XJ7eqSFRAoEdDK0MiSUcl
HBpb1nbXjpR5+yyvZfp3bZjAAY6DG1P4vxAsa9CUMN5iPGCc+5twXhK/sz4hKKca
u+aa68xt/kTeh9QWzQDWz1bXEHME2ag7q7VDrwqdQ6gX4+dJJ2pA19kpeTIyFbQ8
lLRMK74tw89MOlOzuY7wasqAAhPfvR30a/wF4VP8cQDMKUrW92pMVg==
=aqV4
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: new.dat
Type: application/octet-stream
Size: 906 bytes
Desc: not available
Url : /pipermail/attachments/20050803/77c78feb/new-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1px.jpg
Type: image/jpeg
Size: 634 bytes
Desc: not available
Url : /pipermail/attachments/20050803/77c78feb/1px-0001.jpg