From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/64741 Path: news.gmane.org!not-for-mail From: Adrian Aichner Newsgroups: gmane.emacs.gnus.general Subject: Re: EasyPG 0.0.12 Date: Wed, 30 May 2007 07:24:09 +0000 (UTC) Message-ID: References: <734fd533-6d2b-46d1-964c-8d23c4c952e0@well-done.deisui.org> <646dvu6g.fsf@mx.qsc.de> <716b7bce-fb42-4e76-89f3-9d798a2d1e14@well-done.deisui.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1180509875 19633 80.91.229.12 (30 May 2007 07:24:35 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 30 May 2007 07:24:35 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M13252@lists.math.uh.edu Wed May 30 09:24:34 2007 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.50) id 1HtIXq-0003yR-BO for ding-account@gmane.org; Wed, 30 May 2007 09:24:34 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1HtIXk-0005AS-Cu; Wed, 30 May 2007 02:24:28 -0500 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1HtIXj-0005AE-28 for ding@lists.math.uh.edu; Wed, 30 May 2007 02:24:27 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtp (Exim 4.67) (envelope-from ) id 1HtIXh-0001ZY-B1 for ding@lists.math.uh.edu; Wed, 30 May 2007 02:24:26 -0500 Original-Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1HtIXg-0007K0-00 for ; Wed, 30 May 2007 09:24:24 +0200 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HtIXf-0007wq-OW for ding@gnus.org; Wed, 30 May 2007 09:24:24 +0200 Original-Received: from port-212-202-78-14.dynamic.qsc.de ([212.202.78.14]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 May 2007 09:24:23 +0200 Original-Received: from adrian by port-212-202-78-14.dynamic.qsc.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 May 2007 09:24:23 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 59 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: main.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 212.202.78.14 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3) X-Spam-Score: -2.6 (--) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:64741 Archived-At: Daiki Ueno unixuser.org> writes: > > >>>>> In post.gmane.org> > >>>>> Adrian Aichner xemacs.org> wrote: > > > > The biggest issue I found is that ediff-revision will not work with it > > > > out of the box. > > The issue, as I understand it, is that data written to disk into files > > matching epa-file-name-regexp with write-region cannot just always be > > encrypted. > > > It that data is coming from processes, like "cvs update ..." via > > vc-find-version then it is already/still encrypted. > > > Perhaps I am missing some obvious point how to solve this problem. > > I see there are two different issues. The first is, vc-find-version > doesn't inhibit file-name-handlers when creating backup files, as you > mentioned above. The second is, if you want to make diffs for decrypted Hi Daiki! ah, inhibiting file-name-handlers might be an option, even though I don't know whether it will break existing cusomizations out there. > text, it has to be written into files since ediff calls the external > program to compute diffs. Which may cause a security problem unless > Emacs warns about it. But epg does this already for epg-decrypt-file epg-decrypt-string and the the encrypt and verify functions as well. In this ediff-revision case data would still go to disk encrypted (but encrypted only once). > > Something different. jka-compr seems to have the same issue on "*.gz" > files. So... can this kind of problem be better solved by advices (or > hooks, if any) to ediff-revision? No, by the time ediff-revision kicks in, the damage is already done. The file written to disk by vc-find-version has been encrypted one more time. Perhaps I try the inhibit file handlers ideea of your. BTW, I'm running with CVS EasyPG now, and I'm happy to confirm the XEmacs compatibility and buffer-modified issues fixed. Best regards! Adrian > > Regards,