interesting encryption/encoding allout problem

interesting encryption/encoding allout problem

[Ken Manheimer]

i'm struggling with an interesting coding-system problem presented by
allout's topic encryption feature, and wondering whether anyone has
suggestions.

the problem occurs when non-ascii text, which requires an alternative
coding system, exists only within a topic or topics that are encrypted.
allout auto-encrypts unencrypted topics, and i can make allout do
select-safe-coding-system to promote the proper coding system setting
during encryption.

the problem is that encryption of the text removes the need for the
alternate coding system.  when the file is next visited, all the non-ascii
characters are encrypted, which is coding-system agnostic.  the default
coding system is used, and (unless the default happens to be tailored for
it) decryption of the topics will deliver the non-ascii text into the wrong
coding system.

perhaps the thing i'm missing is the right way to save the text so the
alternate coding system is recovered despite the absence of any text which
requires it.  is that possible?  might i need to have allout set some local
file variable to preserve the coding-system?

i think the same problem occurs for whole-buffer encryption, when some of
the encrypted text is non-ascii.
-- 
ken
ken.manheimer@gmail.com
http://myriadicity.net

Re: interesting encryption/encoding allout problem

[Kim F. Storm]

I guess this problem means that we should not install your latest
patches to do the topic encryption.


"Ken Manheimer" <ken.manheimer@gmail.com> writes:

> i'm struggling with an interesting coding-system problem presented by
> allout's topic encryption feature, and wondering whether anyone has
> suggestions.
>
> the problem occurs when non-ascii text, which requires an alternative
> coding system, exists only within a topic or topics that are encrypted.
> allout auto-encrypts unencrypted topics, and i can make allout do
> select-safe-coding-system to promote the proper coding system setting
> during encryption.
>
> the problem is that encryption of the text removes the need for the
> alternate coding system.  when the file is next visited, all the non-ascii
> characters are encrypted, which is coding-system agnostic.  the default
> coding system is used, and (unless the default happens to be tailored for
> it) decryption of the topics will deliver the non-ascii text into the wrong
> coding system.
>
> perhaps the thing i'm missing is the right way to save the text so the
> alternate coding system is recovered despite the absence of any text which
> requires it.  is that possible?  might i need to have allout set some local
> file variable to preserve the coding-system?
>
> i think the same problem occurs for whole-buffer encryption, when some of
> the encrypted text is non-ascii.
> -- 
> ken
> ken.manheimer@gmail.com
> http://myriadicity.net

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: interesting encryption/encoding allout problem

[Ken Manheimer]

On 11/11/06, Kim F. Storm <storm@cua.dk> wrote:

> I guess this problem means that we should not install your latest
> patches to do the topic encryption.

that's right - don't check it in.  i do think those fixes are correct,
but fail to address the issue you cite, below.  i also believe i have
a fairly sensible fix for that additional problem, and hope to have a
patch for it tomorrow or monday.  i'm glad you asked - now i can
simply make the patch against the currently checked-in version of
allout.el, without complicating anybody's life.

(if anyone is interested - i plan to have allout always check whether
text being encrypted needs coding system accomodation different than
that prevailing for the buffer.  if so, the user is prompted for the
coding system (using select-safe-coding-system), and then the new
coding system is preserved using a file local variable setting for
buffer-file-coding-system.  (fortunately, allout already has a
mechanism for establishing and changing the settings of such things.)
the normal safe-local-variable properties will cause people visiting a
file with such a setting to be prompted to accept the setting, so that
they'll be alerted that the setting is in effect.  the situation
rarely should occur, and i think that's the best i can do to provide
for such a complicated character encoding situation...)

ken

> "Ken Manheimer" <ken.manheimer@gmail.com> writes:
>
> > i'm struggling with an interesting coding-system problem presented by
> > allout's topic encryption feature, and wondering whether anyone has
> > suggestions.
> >
> > the problem occurs when non-ascii text, which requires an alternative
> > coding system, exists only within a topic or topics that are encrypted.
> > allout auto-encrypts unencrypted topics, and i can make allout do
> > select-safe-coding-system to promote the proper coding system setting
> > during encryption.
> >
> > the problem is that encryption of the text removes the need for the
> > alternate coding system.  when the file is next visited, all the non-ascii
> > characters are encrypted, which is coding-system agnostic.  the default
> > coding system is used, and (unless the default happens to be tailored for
> > it) decryption of the topics will deliver the non-ascii text into the wrong
> > coding system.
> >
> > perhaps the thing i'm missing is the right way to save the text so the
> > alternate coding system is recovered despite the absence of any text which
> > requires it.  is that possible?  might i need to have allout set some local
> > file variable to preserve the coding-system?
> >
> > i think the same problem occurs for whole-buffer encryption, when some of
> > the encrypted text is non-ascii.
> > --
> > ken
> > ken.manheimer@gmail.com
> > http://myriadicity.net
>
> --
> Kim F. Storm <storm@cua.dk> http://www.cua.dk

-- 
ken
ken.manheimer@gmail.com
http://myriadicity.net