21.5.x crypt.el + MULE + encoding bug (and potential fix)
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