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: lisp/url/url-https.el Date: Thu, 15 Apr 2004 01:42:27 +0200 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> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1081986664 10746 80.91.224.253 (14 Apr 2004 23:51:04 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 14 Apr 2004 23:51:04 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Apr 15 01:50:58 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 1BDu9i-0002QD-00 for ; Thu, 15 Apr 2004 01:50:58 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BDu9i-0001AI-00 for ; Thu, 15 Apr 2004 01:50:58 +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 1BDu8W-0002e6-7G for emacs-devel@quimby.gnus.org; Wed, 14 Apr 2004 19:49:44 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BDu8N-0002ch-Qu for emacs-devel@gnu.org; Wed, 14 Apr 2004 19:49:35 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BDu20-0008P4-AD for emacs-devel@gnu.org; Wed, 14 Apr 2004 19:43:33 -0400 Original-Received: from [80.91.224.249] (helo=main.gmane.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BDu1e-0007yo-Cv for emacs-devel@gnu.org; Wed, 14 Apr 2004 19:42:38 -0400 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BDu1a-0007Hl-00 for ; Thu, 15 Apr 2004 01:42:34 +0200 Original-Received: from h43n3c1o273.bredband.skanova.com ([217.208.170.43]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Apr 2004 01:42:34 +0200 Original-Received: from jas by h43n3c1o273.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Apr 2004 01:42:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Lines: 37 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: h43n3c1o273.bredband.skanova.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:r8i7rY+xPxq2MYT16XmCBsBm/7Q= 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:21664 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:21664 Stefan Monnier writes: >> I am willing to work with any standards Emacs has, but there has to be >> some way to allow a willing user to plug in encryption code easily >> into Gnus, once that code is downloaded. As it is, and according to >> what you have told Lars Magne Ingebrigtsen and he has relayed to the >> Gnus developers, not even empty wrapper functions that could be used >> for encryption are allowed. That makes my life much harder. > > 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. > > 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). > > 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. > > Wait isn't something like that already available? There is crypt++, but when it was discussed in the context of Gnus, I think it was decided it was not really good enough, the programmatic elisp API insufficient, and that we could never get copyright papers for it anyway. I believe it was suggested to make a generic package for this. This same problem does indeed occur in many situations. I thought, but perhaps I have just been secretly wishing it, that Ted was working on something like that.