From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: lisp/url/url-https.el Date: Thu, 15 Apr 2004 11:38:32 -0400 Organization: =?koi8-r?q?=F4=C5=CF=C4=CF=D2=20=FA=CC=C1=D4=C1=CE=CF=D7?= @ Cienfuegos Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <4n1xmpi747.fsf@b2-25-3.bwh.harvard.edu> References: <87fzb8cfxq.fsf@lexx.delysid.org> <4nvfk2whna.fsf@lifelogs.com> <87vfk28bl0.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1082045440 32332 80.91.224.253 (15 Apr 2004 16:10:40 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 15 Apr 2004 16:10:40 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Apr 15 18:10:28 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 1BE9Rb-0002iA-00 for ; Thu, 15 Apr 2004 18:10:27 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BE9Rb-0006Et-00 for ; Thu, 15 Apr 2004 18:10:27 +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 1BE9Q2-000159-QY for emacs-devel@quimby.gnus.org; Thu, 15 Apr 2004 12:08:50 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BE9AM-00041B-0w for emacs-devel@gnu.org; Thu, 15 Apr 2004 11:52:38 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BE94h-0001GM-3D for emacs-devel@gnu.org; Thu, 15 Apr 2004 11:47:18 -0400 Original-Received: from [80.91.224.249] (helo=main.gmane.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BE8v7-0006Ck-Bs for emacs-devel@gnu.org; Thu, 15 Apr 2004 11:36:53 -0400 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BE8v6-0002aC-00 for ; Thu, 15 Apr 2004 17:36:52 +0200 Original-Received: from b2-25-3.bwh.harvard.edu ([134.174.54.60]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Apr 2004 17:36:52 +0200 Original-Received: from tzz by b2-25-3.bwh.harvard.edu with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Apr 2004 17:36:52 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Lines: 48 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: b2-25-3.bwh.harvard.edu X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (usg-unix-v) Cancel-Lock: sha1:+4u++sGNVkLIongiD0JHm6AF2zI= 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:21704 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:21704 On 14 Apr 2004, monnier@iro.umontreal.ca wrote: > My understanding is that the problems only show up for code that's > meant specifically for encryption. So you should be able to provide > hooks as long as they are not specifically for encryption. So is gnus-encrypt.el, which will contain empty hooks that the rest of Gnus uses, a problem? Or do I have to call it gnus-file-handlers.el to pretend it's not what it is? > I know nothing about your specific problem so I'm probably talking > non-sense, but why should .authinfo and Gnus be so special? > > 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. 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). I discussed with Karl Berry, who maintains crypt++.el, and my decision was to write a new package (gencrypt.el) which would provide what crypt++.el provides, but as functions to be used by other packages, rather than as a transparent layer on top of all Emacs file I/O. 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. > 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. gencrypt.el aims to provide a few pure-Lisp ciphers, as well. That would make it useful for those who don't install external encryption software. > And then somehow make sure Gnus can be customized to use > .authinfo.gz (or .authinfo.gpg). That's the easy part :) Ted