21.5.x crypt.el + MULE + encoding bug (and potential fix)

[Barry Warsaw]

FTR I am using Carbon XEmacs 21.5.27 but I don't think this problem is 
specific to Carbon XEmacs.  It seems to also happen for me with 
DarwinPorts XEmacs 21.4.17.  I /think/ it might happen only in a 
MULE-ified XEmacs on OSX.

So the issue is that I use crypt.el to view and write encrypted files 
using GPG (1.4.3 but I don't think that matters either).  When I made 
the switch to MULE on Linux I realized that I have to use C-u C-x f to 
specify the 'binary encoding when visiting an encrypted file.  Now that 
I'm on OSX almost exclusively I've come to realize this isn't enough.

The problem is that when you write an encrypted file, crypt.el corrupts 
the resulting file.  To reproduce, in a shell just encrypt a text file 
using some symmetric key, then visit the file in XEmacs with crypt.el. 
  Make a change to the file and write it back out.  The newly written 
file will be corrupt and cannot be decrypted in the shell with the same 
symmetric key.  One symptom is that gpg will complain with:

gpg: packet with S2K 3 too short

There's almost nothing on the web about this problem, at least that my 
Google-fu was able to find.  I did find some older messages from about 
2003 but it looks like those patches have been applied to 
code-process.el already and aren't relevant.

Anyway, through quite a bit of testing what appears to be happening is 
that \r's in the original encrypted text are getting converted to \n's 
when read from call-process.  It's also possible that they will get 
converted when written back out to file.  This happens even when the 
buffer's coding is 'binary, and it's obvious to see how this will 
corrupt the saved encrypted file.

My fix for this is in crypt.el's crypt-write-file-hook function.  I'm 
sorry I don't have a diff, but the fix is fairly simple.  OTOH, I'm not 
sure it's the /right/ fix.  In any event, in the let (see ;; BINDINGS) 
at about line 1689 which encloses the calls to crypt-encrypt-buffer and 
write-region, I've added these bindings:

	(coding-system-for-read 'binary)
	(coding-system-for-write 'binary)

It appears that both are necessary.  With this fix I can read and write 
encrypted files again! :)

I believe I'm using the latest crypt.el from os-utils 1.37 (crypt.el 
says 2.83 at the top).  Please let me know if you think a better fix is 
in order.  I'll be happy to test anything to get this fixed in the next 
package release.

Cheers,
-Barry