From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel,gmane.emacs.gnus.general Subject: Re: encrypt.el in No Gnus 0.7 Date: Thu, 08 Nov 2007 20:39:09 -0600 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: References: <87zly3y4ru.fsf@catnip.gol.com> <54a15d860711071658j40e1af43r6be4fb0f44ece932@mail.gmail.com> <54a15d860711071716g76be1cc1iaa340dce27a54896@mail.gmail.com> <54a15d860711081511l309d6be5tec3ba3c88e5ebfc3@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1194575981 13671 80.91.229.12 (9 Nov 2007 02:39:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 9 Nov 2007 02:39:41 +0000 (UTC) Cc: miles@gnu.org, rms@gnu.org, ding@gnus.org, emacs-devel@gnu.org To: "Daiki Ueno" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 09 03:39:44 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IqJmY-0000Ty-PX for ged-emacs-devel@m.gmane.org; Fri, 09 Nov 2007 03:39:43 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IqJmN-0005vS-3m for ged-emacs-devel@m.gmane.org; Thu, 08 Nov 2007 21:39:31 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IqJmJ-0005s3-2h for emacs-devel@gnu.org; Thu, 08 Nov 2007 21:39:27 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IqJmG-0005kq-1R for emacs-devel@gnu.org; Thu, 08 Nov 2007 21:39:26 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IqJmF-0005kb-Th for emacs-devel@gnu.org; Thu, 08 Nov 2007 21:39:23 -0500 Original-Received: from blockstar.com ([170.224.69.95] helo=mail.blockstar.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IqJm6-0003WW-SF; Thu, 08 Nov 2007 21:39:15 -0500 Original-Received: from mungo.local (c-67-186-103-18.hsd1.il.comcast.net [67.186.103.18]) by mail.blockstar.com (Postfix) with ESMTP id 1017B3F8576; Thu, 8 Nov 2007 19:01:14 -0800 (PST) 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" Mail-Followup-To: "Daiki Ueno" , rms@gnu.org, emacs-devel@gnu.org, ding@gnus.org, miles@gnu.org In-Reply-To: <54a15d860711081511l309d6be5tec3ba3c88e5ebfc3@mail.gmail.com> (Daiki Ueno's message of "Fri, 9 Nov 2007 08:11:00 +0900") User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1.50 (darwin) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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: news.gmane.org gmane.emacs.devel:82839 gmane.emacs.gnus.general:65605 Archived-At: On Fri, 9 Nov 2007 08:11:00 +0900 "Daiki Ueno" wrote: DU> You apperantly misinterpreted their non-negative opinions as positive DU> supports of including encrypt.el. DU> I think their opinions are neutral. They should be considered as 0. DU> Now the score is 1-2 (including you, RMS and me). Are you alright? As I said, I'm asking for votes from everyone, including Reiner and Stefan, so we don't get mired in semantics. If votes are conditional ("I'd want encrypt.el if it did X") that's fine, I can answer those questions. >> I think I have said enough on the topic to make up everyone's mind. >> I will integrate with rijndael.el if anyone needs that. DU> I think you haven't told enough. I asked what kind of people do you DU> think of your users, again and again. You just told about your DU> imaginary users. Well, I've been supporting Emacs users for a while with various Gnus and Emacs questions, so I have some idea of what they like. I may be wrong, but I am working in good faith to provide users what I think they want. I have not advertised the library so I don't have user feedback. DU> IIUC, your users must satisfy at least one of the following conditions: DU> (1) They have some difficulties on installing GnuPG. DU> (2) They are so interested in cryptography that they want to select DU> ciphers or rather to implement them, and want to use their ciphers DU> through too ristricted file-based API. DU> I estimate the user base to be quite few. You're not exactly right. I also want to help users who can't or won't install GnuPG (this is common for me when I administer Unix systems; on Windows machines users may not have permission to install it even for themselves, etc.). Furthermore, GnuPG is not the only encryption tool available, so it's not fair to the users to assume (1) applies to them. The encrypt.el API can change as needed. The idea of a simple standard encryption API is more important to me than the implementation. I see no reason why the API should not support string and buffer encryption; if you or anyone else would like to see that in encrypt.el then let me know. The essentials, to me, are 1) flexible models that can accomodate EasyPG and other libraries, especially user-supplied ciphers and interfacing with external steganographic tools. I think these models should actually be stackable, e.g. "hide and encrypt my passwords in this image." 2) easy configuration by the user (thus the file-based setup right now, because it's familiar to Emacs users). 3) easy API for those who need to integrate it into their code (but this should be efficient so we don't store data in memory unnecessarily, of course) 4) non-invasive (no hidden hook action, etc.) If you agree with these goals, great. I apologize if they were not clear before. DU> Otherwise we should make GnuPG installation easier, or provide more DU> flexible API for user-defined ciphers, including encryption of DU> strings and buffers as well as files, support for public key DU> encryption, or other many important features that encrypt.el lacks. It's not clear if you are interested in working with me to improve encrypt.el or only within EasyPG to achieve those goals. Either way, I'll be glad to assist you any way I can. Ted