Issue with photo ID's

David Shaw dshaw at jabberwocky.com
Mon Jan 5 19:25:30 CET 2004


On Tue, Jan 06, 2004 at 12:02:59AM +0100, Patrick Brunschwig wrote:
> I am implementing displaying of photo ID's in Enigmail. On Linux, all
> works as expected, but on Windows I'm encountering a problem.
> Since I want to display the photo from from within Mozilla, I read the
> picture using
> "gpg --status-fd 3 --attribute-fd 4 --list-keys 0x<16byte-key>"
> 
> On Linux, I get the "[GNUPG:] ATTRIBUTE ..." line, followed by the jpeg
> data as expexted. But on Windows, all \n (0x0D) are converted to \r\n
> (0x0A0D), even inside the jpeg data, so that the picture is corrupt. I
> have tried gpg 1.2.2 and gpg 1.2.4.
> 
> Is this a (known?) bug of gpg, or is this expected behaviour?
> Of course, I could convert \r\n back to \n (which indeed makes the jpeg
> display correctly), but I don't feel very safe with this! And how would
> it be e.g. on MacOS?

I think I know what the problem is.  The attribute-fd is opened in
GnuPG via something like fdopen(attribute_fd,"w").  That works fine on
POSIX systems, since text and binary files are treated the same.  It
seems that the Mingw32 stdio stuff doesn't treat them the same.  I
expect that MacOS, being POSIX, would not mangle the data.

I'll force the output into binary mode for the next GnuPG release, but
that doesn't help you much for Enigmail today, since Win32 users would
have to upgrade to a fixed GnuPG before they could view photo IDs.
You could do an ugly workaround with a special photo-viewer:

gpg --photo-viewer "helper_app_to_send_photo_to_enigmail" --show-photos --list-keys 0x....

Probably the easiest fix is that Cygwin has a magic environment
variable to fix this (it's a common problem): just set CYGWIN=binmode
(or rather add binmode to any existing contents of $CYGWIN).  Werner,
does your special Mingw32 have something like that?

I suppose in the worst case you could translate the \r\n back to \n.
Just do it only on Windows and only for GnuPG <= 1.2.4.  You'd have to
do some testing to see whether a "real" \r\n is translated into \r\r\n
or passed through unchanged (in which case you have another problem!)

David
-------------- next part --------------
Index: keylist.c
===================================================================
RCS file: /cvs/gnupg/gnupg/g10/keylist.c,v
retrieving revision 1.37.2.18
diff -u -r1.37.2.18 keylist.c
--- keylist.c	31 Aug 2003 03:37:17 -0000	1.37.2.18
+++ keylist.c	5 Jan 2004 23:52:03 -0000
@@ -1136,7 +1136,7 @@
   else if( fd == 2 )
     attrib_fp = stderr;
   else
-    attrib_fp = fdopen( fd, "w" );
+    attrib_fp = fdopen( fd, "wb" );
   if( !attrib_fp ) {
     log_fatal("can't open fd %d for attribute output: %s\n",
 	      fd, strerror(errno));



More information about the Gnupg-devel mailing list