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

[Stephen J. Turnbull]

>>>>> "BAW" == Barry Warsaw <barry at python.org> writes:

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

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

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

I don't use crypt, so I can't say for sure, but your theory is right
and this is the theoretically correct fix.

I'll fiddle with it a bit, but the main thing that would hold up a
package release IMO is writing a test suite.

It's a bit of a kludge, but I think what can be done is to add a file
to the *core* test 

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



-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.