From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.devel Subject: Re: Moving files from lisp/gnus/ to lisp/net/? Date: Mon, 01 Nov 2004 21:31:47 +0100 Message-ID: References: <2366.81.51.30.174.1098020712.squirrel@yxa.extundo.com> <4nekjd9vqk.fsf@lifelogs.com> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1099341158 16461 80.91.229.6 (1 Nov 2004 20:32:38 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 1 Nov 2004 20:32:38 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 01 21:32:29 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1COiqr-0006qO-00 for ; Mon, 01 Nov 2004 21:32:29 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1COiys-0002WU-Co for ged-emacs-devel@m.gmane.org; Mon, 01 Nov 2004 15:40:46 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1COiyj-0002WJ-7X for emacs-devel@gnu.org; Mon, 01 Nov 2004 15:40:37 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1COiyi-0002Vu-DX for emacs-devel@gnu.org; Mon, 01 Nov 2004 15:40:36 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1COiyi-0002Vr-9n for emacs-devel@gnu.org; Mon, 01 Nov 2004 15:40:36 -0500 Original-Received: from [80.91.229.2] (helo=main.gmane.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1COiqK-0003VO-QS for emacs-devel@gnu.org; Mon, 01 Nov 2004 15:31:57 -0500 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1COiqK-0004VG-00 for ; Mon, 01 Nov 2004 21:31:56 +0100 Original-Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 01 Nov 2004 21:31:56 +0100 Original-Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 01 Nov 2004 21:31:56 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-To: emacs-devel@gnu.org Original-Lines: 33 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se Mail-Copies-To: nobody User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:0qnK+ui57KJFU2yP1Wu4JD5dYmI= 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: main.gmane.org gmane.emacs.devel:29279 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:29279 Ted Zlatanov writes: > On Fri, 29 Oct 2004, jas@extundo.com wrote: > >> It was added later on, not by me. I suppose he who added it might >> argue that it is useful, though. I tend to think that there should >> only be one worked out interface. (I'm not saying the current API, >> without p-r-a-a is the best interface, only that it would be better >> with only one interface.) > > I added it for the purpose of decrypting a file, which is a one-shot > deal. If it fails, it fails - you don't try to reopen the file as you > would a network connection, and you don't necessarily know that it > failed (for example, the encrypt.el XOR cipher produces garbage with a > bad password but otherwise there's no indication that there was an > error). The only problem is that the password is then memorized, so > if it was bad it will stay around. > > Either I should add an option to ask y/n if the decryption was OK > after the first time a password is entered, or I will give the user a > way to clear a bad password. Any other suggestions are welcome. > Please note again that we don't necessarily know the decryption > failed. Maybe we should not memorize encryption passwords at all? > That would be tedious, though, if you encrypt a lot of files with the > same cipher... I understand the problem. One solution is to simply not use encryption methods that doesn't provide integrity? Then the decryption process would know if the password worked or not. I believe that, in general, encryption mechanisms that do not offer integrity protection are questionable. The XOR key derivation from password seem a bit fragile, too. On the other hand, I realize that only using GnuPG may create more work for the user.