Re: pgg symmetric encryption patch

[Ken Manheimer <ken.manheimer@gmail.com>]

On 10/7/05, Sascha Wilde <wilde@sha-bang.de> wrote:
> On Thu, Oct 06, 2005 at 06:41:14PM -0400, Ken Manheimer wrote:
>
> > which) involve this pgg code with sascha's most recent symmetric-key
> > extensions patch (emacs-pgg-symmetric.patch-03) applied (by hand -
> > couldn't get it to work using 'patch').
>
> hmm, strange, I just applied the patch to a fresh GNU emacs cvs
> checkout w/o any problems -- only one changelog hunk failed, no
> wonder, the changelogs are constantly changing...  ;-)

ironically, this was a due to the patch file having DOS-style line
endings.  i didn't notice the "(DOS)" indicator on the emacs mode line
- but did notice it when i just looked at the .rej files.  i visited
the file "literally" ('find-file-literally') and stripped the ^Ms, and
the patch worked.

(to complicate matters a little, 'patch' compensated for the ^M line
endings in the new patch you sent (pgg-gpg_textmode.patch).  i don't know why
that compensation didn't happen with the other patch - maybe something to
do with this one being for a single file and the other being multi?
aargh.)

> > 1. my most serious concern is with the unpatched pgg code.  the text that
> >    it encrypts is altered from the original, in order to append \r carriage
> >    returns to the text (using pgg-as-lbt / pgg-convert-lbt).
> >
> >    the problem with this is that decryption on unix-ish platforms with
> >    anything other than pgg will result in text that is different than the
> >    original.
>
> This is supposed to be a feature, not a bug.
> But read on, there actually _is_ a bug in PGG...
>
> Please note RfC 2440  5.9.:
>
> The last sentence gives a short summary on the subject
>
>    Text data is stored with <CR><LF> text endings (i.e. network-normal
>    line endings).  These should be converted to native line endings by
>    the receiving software.
>
> As PGG tries to implement RfC conform OpenPGP, and it handles is text,
> not binary data, this always applies.
>
> Please read also on the `--textmode' option of gpg.
>
> THE BUG: pgg does the newline conversion by it self (I'm not quite
> sure why) but fails to tell the backend (gpg) that it should operate
> in textmode, so the Data Packet is tagged as binary, not text data...

pgg is definitely doing the wrong thing in converting the text to DOS
format, itself.  that requires that pgg be the decryption program used
if the platform where the message is being decrypted does not use DOS
file-encoding.

> Please try if the appended patch (only against pgg-gpg.el) fixes this
> issue.

that didn't work, but lead me in the right direction to what looks like the fix.

it does work if you also remove the invocation of the pgg-as-lbt macro
which encloses the pgg-gpg-process-region call.  i'm including a patch
which does that for all of the pgg-gpg.el routines which use
pgg-as-lbt.

once again, i'm not *sure* that's the right thing, but i'm pretty sure
that the way pgg-as-lbt is being used is the wrong thing.  maybe that
was done to try to provide for versions of gpg that lacked the
--textmode option. i don't think that would be a good idea.

(since pgg-as-lbt is a macro, its effect is a little beguiling.  it
does its processing _before_ the call to pgg-gpg-process-region,
despite the fact that the latter is placed as an argument to the
former, and in contrast to what would happen in regular functions,
where the innermost call would be conducted first...)

> [passphrase caching]
>
> As I'm short of time, I'll look into this issues later, sorry...

i've resolved part of the problem in my patch, specifically:

> > 3. this key caching problem of #2 is compounded in the context of sascha's
> > [...]
> > - the patched version will use the prompt for the symmetric key even when
> >   doing a public-key decryption.

the problem was that the 'result' value in dolist was being setq'd,
but not made local, so the previous result is used in the case that no
new result is found.  i added a '(let (result) ...)' around the
dolist, and it's now behaving properly.  that's in my version of your
patch.

caching of the symmetric passphrase is going to take some more thought.

what i did in allout is to manipulate mailcrypt's caching mechanism to
cache the symmetric key according to the file path, if any, else the
buffer name.  that way, there's one symmetric key cached per file.  on
top of that, there's allowance in the password reading mechanism for
new or varying symmetric keys for a file, with provision for
presenting a user-supplied key hint in the prompt, as well.  i would
like to refine pgg's password prompting mechanism to make it easy for
allout to provide the prompt and other behaviors without making it too
specialized and complicated.  i'm going to leave that for a separate
patch, once i get it done.

finally (with regard to the passphrase stuff), pgg should be caching
the key-pair mode passphrases according to the actual identity of the
key being addressed, and not the default user id.  that info is
available explicitly when encrypting, and i suspect that your
pgg-gpg-symmetric-key-p demonstrates that it's available (via
pgg-decode-armor-region) when decrypting.  the caching should
discriminate, and the decryption prompt should indicate, on the basis
of that info, but i'll leave it to someone else to make those
refinements to the pgg code.  i'm going to just try to make sure the
caching and password reading mechanisms are general enough.

> > 4. in the patched version, the symmetric encryption does not replace the
> >    original text with the encrypted text - it's only available in the
> >    hidden " *PGG output*" buffer, but not put in place.
>
> I think, you want to use `pgg-encrypt-symmetric-region', which
> encapsulates the backend function `pgg-gpg-encrypt-symmetric-region'
> and puts the encrypted text in place.

you're correct, that was my mistake.

we're making some good progress here.  the --textmode fact was crucial
- it's looking like the use of pgg-as-lbt is somehow misguided.  i'm
hoping that the major things are taken care of, and i can refine the
passphrase caching mechanism as i see necessary.

thanks for your help!

ken manheimer
ken.manheimer@gmail.com