From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: libnettle/libhogweed WIP Date: Wed, 17 May 2017 16:05:01 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87r2znntaq.fsf@lifelogs.com> References: <87wpamww9k.fsf@lifelogs.com> <8337daggnj.fsf@gnu.org> <87d1cdwxt6.fsf@lifelogs.com> <83tw5pg1q3.fsf@gnu.org> <87zifhulc2.fsf@lifelogs.com> <83h91og80k.fsf@gnu.org> <87pogbuhoe.fsf@lifelogs.com> <834lxndmd9.fsf@gnu.org> <87efwrug6z.fsf@lifelogs.com> <87r30qu5av.fsf@lifelogs.com> <874lxmtxyy.fsf@lifelogs.com> <87r30prvwt.fsf@lifelogs.com> <8337d4csez.fsf@gnu.org> <87r30nq9el.fsf@lifelogs.com> <83inlyc1k2.fsf@gnu.org> <87inlyrfni.fsf@lifelogs.com> <837f2eb845.fsf@gnu.org> <87ziedpyy1.fsf@lifelogs.com> <83d1b75u8a.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1495051572 3131 195.159.176.226 (17 May 2017 20:06:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 17 May 2017 20:06:12 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 17 22:06:08 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dB5Cv-0000eo-RX for ged-emacs-devel@m.gmane.org; Wed, 17 May 2017 22:06:05 +0200 Original-Received: from localhost ([::1]:50579 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dB5Cz-0004kw-Rs for ged-emacs-devel@m.gmane.org; Wed, 17 May 2017 16:06:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52384) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dB5CA-0004kn-4z for emacs-devel@gnu.org; Wed, 17 May 2017 16:05:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dB5C5-0002VO-PN for emacs-devel@gnu.org; Wed, 17 May 2017 16:05:18 -0400 Original-Received: from [195.159.176.226] (port=42549 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dB5C5-0002VC-IR for emacs-devel@gnu.org; Wed, 17 May 2017 16:05:13 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1dB5Bv-0007ot-5I for emacs-devel@gnu.org; Wed, 17 May 2017 22:05:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 68 Original-X-Complaints-To: usenet@blaine.gmane.org 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-Copies-To: never Cancel-Lock: sha1:c+NHcCjcRr7dcwXIMJLmDYvQ9z8= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:214928 Archived-At: On Wed, 17 May 2017 19:22:13 +0300 Eli Zaretskii wrote: >> From: Ted Zlatanov >> Date: Mon, 15 May 2017 17:55:34 -0400 >> >> On Fri, 21 Apr 2017 09:14:02 +0300 Eli Zaretskii wrote: EZ> It's hard to have a dialog with 4 weeks between responses ;-) Sorry, I had finals, had to prioritize. EZ> I don't think this could be the case. We are talking about using EZ> these APIs in Emacs Lisp programs, where objects being manipulated EZ> aren't C strings, and where file I/O is relatively rare and mostly EZ> implied. The use cases I was asking about are use cases for Lisp EZ> programs. I expect most early use cases to be simply existing applications already using EPA/EPG or nothing taking advantage of this functionality to upgrade security opportunistically or forcefully, especially on platforms and in situations where GnuPG is not available or suitable. An indirect way is to look for applications in the Emacs source that use EPA/EPG or auth-source: Tramp, RMAIL, Gnus (mail and cloud), Dired, allout-mode, plstore, Org, ERC, EWW, url. Maybe that's helpful? Below I'll list some use cases differentiated by usage modes but not really at the application level; I hope that's a helpful complement to the explanation above. One use case is signing a data message (text or binary, string or file) quickly. Another: keep data on disk encrypted and only decrypt it exactly when it's needed, then wipe it. The key or passphrase can be in a file as well, or in a Lisp closure or other opaque storage. That would be ideal for auth-source, for instance. It would enable the same file to work on multiple OS platforms. Another: you don't trust the network but you do trust the security of a shared file. So you encrypt network data with a shared key in a file as it's sent and decrypt it on the other side as it's received, with the same file, without having to read the file into memory. EZ> My point was that the test suite cannot be a use case that drives our EZ> design, because we can tweak any test to fit into any usage pattern we EZ> want. Valid and interesting use cases should come from outside the EZ> test suite, they should come from real-life uses of these features by EZ> Lisp programs. You're right. I hope I was helpful above. >> There also pipes (pretty easy to fit the file model) EZ> How do you fit a pipe into the (file "FOO") model? I'm not very sure about non-Unix, but on Unix platforms they are pretty similar. So I'd just let FOO be a pipe or a file and deal with the differences at the C level. EZ> OTOH, all of these are readable into a buffer, so the buffer model EZ> could easily cover them all, no? Buffers are a kind of Reader API as Lars mentioned, but they have a lot of baggage and visibility to Emacs Lisp code. They're good enough to get us going and we can extend the spec later. Ted