emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: allout encryption and non-ascii characters


From: Ken Manheimer
Subject: Re: allout encryption and non-ascii characters
Date: Tue, 7 Nov 2006 19:13:46 -0500

i still am getting successful encryption/decryption turnaround of your
text with a current cvs checkout.  in the process i realized one
elusive pitfall which could lead to a false negative, and want to warn
you about it.

you need to have some of the non-ascii text outside of an encrypted
topic.  otherwise, emacs auto-encrypts during the save, hiding the
encoded characters from emacs non-ascii detection.  it also
auto-decrypts the current topic after the save, if it was plain text
before, hiding the fact that the encryption happened from the user.
you would notice that the non-ascii text isn't preserved across the
save, but could miss that *emacs* could miss the non-ascii
characters/alternate encoding because of the auto-encryption...

thanks again...

ken


On 11/7/06, Ken Manheimer <address@hidden> wrote:
i've replied to david, and i'm hoping we can track down the
discrepancy between our systems - i'm unable to reproduce his problem
with his text and my posted version of allout.  in the meanwhile, the
request for testers still goes - encryption of non-ascii text with the
(attached) allout version with the fix (after saving and revisiting
the text file, to ensure that the buffer is set to the right
encoding).

ken

On 11/6/06, David Smith <address@hidden> wrote:

> Thanks very much for working on the coding-system related
> bug. Unfortunately, with the attached test file, it still
> fails. I've attached my test file; it's encoded with
> mule-utf-8, I'm using GNU Emacs 22.0.50.1 (i486-pc-linux-gnu,
> GTK+ Version 2.8.20) of 2006-10-23 on pacem, modified by Debian.
>
> Any pgg hackers with a clue on this?
>
> David
>
> "Ken Manheimer" <address@hidden> writes:
>
> > though i haven't heard that anyone else has tested it, i would hate
> > for this allout patch to miss the release, and am confident enough
> > about its merits to ask that it be applied.
> >
> > the crucial thing the patch does is enable topic encryption of
> > non-ascii encodings.  the encoding fix is only a few lines, but the
> > patch also eliminates a tradeoff in the last fix i submitted,
> > clarifies a variable name and some docstrings in the process, and
> > rectifies some assorted boundary-condition behaviors, as well.
> > --
> > ken
> > address@hidden
> > http://myriadicity.net
> >
> > 2006-11-05  Ken Manheimer  <address@hidden>
> >
> >       * allout.el (allout-doublecheck-at-and-shallower): Clarify
> >       docstring.
> >       (allout-inhibit-aberrance-doublecheck): Rename from
> >       allout-during-yank-processing.
> >       (allout-do-doublecheck): Track allout-inhibit-aberrance-doublecheck
> >       name change.
> >       (allout-ascend): Provide for unusual case where some topic after
> >       the first in file is at lower depth than the first.
> >       (allout-shift-in): Ensure the offspring of the new containing
> >       topic are exposed.
> >       (allout-encrypt-string): Preserve the coding-system of the text,
> >       according to that of the containing buffer.
> >
> >
> >
> > On 11/4/06, Ken Manheimer <address@hidden> wrote:
> >> i have had some success with getting allout topic encryption to
> >> encrypt text so that characters in an alternate coding set are
> >> preserved.  i am looking for people to test it - i am so unfamiliar
> >> with coding sets in general that i don't really know how to be sure it
> >> works generally!  (i am excited, though, that i was able to round-trip
> >> some text with an elaborate <'> apostrophe that isn't preserved in the
> >> ascii character set, but is preserved in iso-2022-7bit.)
> >>
> >> i'm attaching a full copy of the revised allout.el for testing - make
> >> sure you're not getting byte code from an old version when giving it a
> >> go.  and when you do test it, be sure that the file you're working
> >> with has a coding set which preserves the characters on rereading -
> >> the encryption depends on the buffer being in the right coding set.
> >>
> >> let me know whether or not it works for you, and if possible, the
> >> coding set of the trial ('Esc-x buffer-file-coding-set' will tell
> >> you).  if i get good confirmation that this works, i'll submit a
> >> proper patch.
> >>
> >> thanks!
> >>
> >> On 11/1/06, Ken Manheimer <address@hidden> wrote:
> >> > allout's use of pgg for encryption doesn't provide for non-ascii text,
> >> > and encoding is a realm where i seem to have less than zero
> >> > cluefulness.  can anyone help me solve the problem posed below?
> >> >
> >> > ken
> >> >
> >> > On 11/1/06, an david smith wrote:
> >> >
> >> > > Hi Ken,
> >> > >
> >> > > I've been an allout user for a very long time. It's wonderful
> >> > > software. Thank you.
> >> > >
> >> > > Today I thought I'd try out the encryption support as I finally
> >> > > have a need for it but it doesn't properly handle non-ascii
> >> > > characters. pgg-output-buffer is created inside of pgg-gpg with
> >> > > mode of raw-text or binary and that is never converted back
> >> > > into the charset of the original cleartext. I do a lot of work
> >> > > in Japanese and so this is critical.
> >> > >
> >> > > I look at how gnus uses pgg and its charset handling but even
> >> > > in edebug I couldn't quite see how it was doing it correctly
> >> > > compared to how allout's method.
> >> > >
> >> > > If you have any insight I would really appreciate it. I will
> >> > > try to debug this in my own time but as you are the
> >> > > maintainer/author of the software involved, I hope you can at
> >> > > least nudge in me the right direction towards a fix.
> >
> >
>
> --
>   David D. Smith
>
>
> Test Text
> //_. Encrypt This
> 筆は剣より強い。
>
>
>
>


--
ken
address@hidden
http://myriadicity.net





--
ken
address@hidden
http://myriadicity.net




reply via email to

[Prev in Thread] Current Thread [Next in Thread]