From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Manheimer Newsgroups: gmane.emacs.devel Subject: Re: pgg symmetric encryption patch Date: Fri, 7 Oct 2005 14:06:55 -0400 Message-ID: <2cd46e7f0510071106k3d4d3e6agc36f16a37d8b6bc6@mail.gmail.com> References: <2cd46e7f0510010928v8244052k2a98375e38fdd2ed@mail.gmail.com> <20051003192503.GA15503@kenny.sha-bang.local> <2cd46e7f0510031250u66ea1349yb437d539ce4027ef@mail.gmail.com> <20051004105330.GA5288@kenny.sha-bang.local> <20051005161905.GA6208@kenny.sha-bang.local> <20051006090152.GB4494@kenny.sha-bang.local> <2cd46e7f0510061541w73bb6a92wb6d22829b6e804ae@mail.gmail.com> <20051007100014.GB4850@kenny.sha-bang.local> Reply-To: Ken Manheimer NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1128708564 7672 80.91.229.2 (7 Oct 2005 18:09:24 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 7 Oct 2005 18:09:24 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 07 20:09:17 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1ENwcn-00083O-8h for ged-emacs-devel@m.gmane.org; Fri, 07 Oct 2005 20:07:17 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ENwcm-0002BF-Ai for ged-emacs-devel@m.gmane.org; Fri, 07 Oct 2005 14:07:16 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ENwcT-00028Q-Nw for emacs-devel@gnu.org; Fri, 07 Oct 2005 14:06:58 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ENwcS-00027F-Ud for emacs-devel@gnu.org; Fri, 07 Oct 2005 14:06:57 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ENwcS-00026b-R1 for emacs-devel@gnu.org; Fri, 07 Oct 2005 14:06:56 -0400 Original-Received: from [64.233.162.207] (helo=zproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1ENwcS-0000Vy-FT for emacs-devel@gnu.org; Fri, 07 Oct 2005 14:06:56 -0400 Original-Received: by zproxy.gmail.com with SMTP id k1so410000nzf for ; Fri, 07 Oct 2005 11:06:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VSe3quE3KApr2PDk6Kg+5J1uqGw8WuzDsU3sGPQf6AebvvfDfjBkpuKLhsHoEMY1CcXNtYEsQ9sXzqqKlCPO/Ysk7OCMLhbIrZiLpc5zYakQO4Y6yBvUQh6CgcBjxed5j9FnsSslNies429CWODSpOJrhmn/YH+B4UALlum6xfQ= Original-Received: by 10.36.196.4 with SMTP id t4mr79839nzf; Fri, 07 Oct 2005 11:06:55 -0700 (PDT) Original-Received: by 10.36.36.11 with HTTP; Fri, 7 Oct 2005 11:06:55 -0700 (PDT) Original-To: Ken Manheimer , "Daiki Ueno (pgg author)" , "sascha schwab (symmetric encryption patches)" , "Simon Josefsson (gnus maintainer of pgg)" , "Richard M. Stallman" , emacs-devel@gnu.org In-Reply-To: <20051007100014.GB4850@kenny.sha-bang.local> Content-Disposition: inline X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:43650 Archived-At: On 10/7/05, Sascha Wilde 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 w= hy 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 th= at > > it encrypts is altered from the original, in order to append \r carr= iage > > 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 t= he > > 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 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 sasch= a's > > [...] > > - the patched version will use the prompt for the symmetric key even wh= en > > 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 th= e > > 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