From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: lisp/url/url-https.el Date: 16 Apr 2004 16:52:20 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <87fzb8cfxq.fsf@lexx.delysid.org> <4nvfk2whna.fsf@lifelogs.com> <87vfk28bl0.fsf-monnier+emacs@gnu.org> <4n1xmpi747.fsf@b2-25-3.bwh.harvard.edu> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1082149602 18560 80.91.224.253 (16 Apr 2004 21:06:42 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 16 Apr 2004 21:06:42 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Apr 16 23:06:35 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BEaXj-0006HK-00 for ; Fri, 16 Apr 2004 23:06:35 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BEaXj-0003R3-00 for ; Fri, 16 Apr 2004 23:06:35 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BEaXa-0004S8-1u for emacs-devel@quimby.gnus.org; Fri, 16 Apr 2004 17:06:26 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BEaXQ-0004Pj-SI for emacs-devel@gnu.org; Fri, 16 Apr 2004 17:06:16 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BEaK6-0007Pp-8I for emacs-devel@gnu.org; Fri, 16 Apr 2004 16:53:01 -0400 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BEaK3-0007Oy-Lo for emacs-devel@gnu.org; Fri, 16 Apr 2004 16:52:27 -0400 Original-Received: from asado.iro.umontreal.ca (asado.iro.umontreal.ca [132.204.24.84]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 8E71C204B4; Fri, 16 Apr 2004 16:52:20 -0400 (EDT) Original-Received: by asado.iro.umontreal.ca (Postfix, from userid 20848) id A39D58B4C3; Fri, 16 Apr 2004 16:52:20 -0400 (EDT) Original-To: Ted Zlatanov In-Reply-To: <4n1xmpi747.fsf@b2-25-3.bwh.harvard.edu> Original-Lines: 54 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-0.001, requis 5, BAYES_44 -0.00) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:21801 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:21801 >> Can't we write a generic "auto-decrypt-mode" which works similarly >> to auto-compress-mode (or maybe even a patch to auto-compress-mode >> which allows "compression using gpg") ? This package wouldn't be >> distributable with Emacs but it doesn't have anything specific to do >> with Gnus and can distributed separately (e.g. from a non-US >> location). > crypt++.el does that. No, it doesn't. auto-compress-mode uses file-name-handler-alist, whereas crypt++ uses things like find-file-hooks. > I find it intrusive, not to mention that it doesn't play nice with many > packages (noted as bugs in the comments of crypt++.el). Using file-name-handler-alist would make it much less intrusive and much more reliable (but would require crypted files to have an easily recognizable name). > I feel that, because of the complexity and variety of encryption programs > and ciphers, a file encryption API is better than the crypt++.el approach. I agree that the implementation technique used by crypt++ is inappropriate (seems to be inherited from way back, probably a time when file-name-handlers-alist wasn't available). But could you explain what a file encryption API would provide that can't be obtained directly from file-name-handlers? >> Or maybe we can even make the patch to jka-compr.el generic enough >> (allow "(de)compression with a program that requires interactive >> user input") to make it acceptable for inclusion in Emacs. > Encryption, unfortunately, is not easy to implement correctly. This > sort of shell pipe could present security risks, for instance, if > done without care. gencrypt.el will do it properly. I don't understand why jka-compr would be restricted to "a shell pipe" in a way that gencrypt.el wouldn't. Could you explain with some concrete examples? Admittedly, I'm of the people would don't believe in overwriting files and data (e.g. I don't see the point of the new clear-string function), so maybe I disagree more than I fail to understand. >> And then somehow make sure Gnus can be customized to use >> .authinfo.gz (or .authinfo.gpg). > That's the easy part :) And the only hook needed to get file-name-handlers in the game. Stefan