From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: libnettle/libhogweed WIP Date: Wed, 17 May 2017 19:22:13 +0300 Message-ID: <83d1b75u8a.fsf@gnu.org> References: <83y3w5z1ez.fsf@gnu.org> <87lgr6yakj.fsf@lifelogs.com> <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> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1495038156 21666 195.159.176.226 (17 May 2017 16:22:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 17 May 2017 16:22:36 +0000 (UTC) Cc: emacs-devel@gnu.org To: Ted Zlatanov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 17 18:22:31 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 1dB1iY-0005Vx-F9 for ged-emacs-devel@m.gmane.org; Wed, 17 May 2017 18:22:30 +0200 Original-Received: from localhost ([::1]:49893 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dB1id-0005xd-VL for ged-emacs-devel@m.gmane.org; Wed, 17 May 2017 12:22:36 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53885) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dB1iW-0005xN-6W for emacs-devel@gnu.org; Wed, 17 May 2017 12:22:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dB1iS-0004xE-69 for emacs-devel@gnu.org; Wed, 17 May 2017 12:22:28 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33389) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dB1iS-0004x8-2h; Wed, 17 May 2017 12:22:24 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3931 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dB1iR-0007yq-AT; Wed, 17 May 2017 12:22:23 -0400 In-reply-to: <87ziedpyy1.fsf@lifelogs.com> (message from Ted Zlatanov on Mon, 15 May 2017 17:55:34 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:214919 Archived-At: > From: Ted Zlatanov > Date: Mon, 15 May 2017 17:55:34 -0400 > > On Fri, 21 Apr 2017 09:14:02 +0300 Eli Zaretskii wrote: It's hard to have a dialog with 4 weeks between responses ;-) > EZ> I think both this and the other sub-thread arrived at a point where it > EZ> is important to present a list of use cases we envision and would like > EZ> to support, because these kinds of decisions are prone to errors if we > EZ> don't hold the use cases in our minds. > > EZ> So could you please present such a list, describing the source of the > EZ> text to be encrypted/decrypted/hashed, the purpose of the operation > EZ> (i.e. some higher-level context), and the destination where the > EZ> encrypted/decrypted/hashed text will go? The list doesn't have to be > EZ> exhaustive, but it should include the most important use cases. > > Right now, I am mirroring the GnuTLS API. That API is in wide use. So I > think the use cases are a large subset of the general GnuTLS use cases; > we're enabling the same things. I don't think this could be the case. We are talking about using these APIs in Emacs Lisp programs, where objects being manipulated aren't C strings, and where file I/O is relatively rare and mostly implied. The use cases I was asking about are use cases for Lisp programs. > > On Fri, 21 Apr 2017 09:21:14 +0300 Eli Zaretskii wrote: > > >> From: Ted Zlatanov > >> Date: Thu, 20 Apr 2017 17:54:32 -0400 > >> > >> The KEY is secret and ideally would come from a file and never be > >> seen at the Lisp level. But tests and other use cases may need it from a > >> buffer (more secure but still accessible to Lisp) or a string (visible > >> to all as a function parameter). > > EZ> For testing, we could always write the key to a file before using it. > EZ> What other use cases would need the key from other sources? > > I think if the key is not on disk, we shouldn't force it to disk just to > fit a always-a-file usage model. My point was that the test suite cannot be a use case that drives our design, because we can tweak any test to fit into any usage pattern we want. Valid and interesting use cases should come from outside the test suite, they should come from real-life uses of these features by Lisp programs. > >> Getting the INPUT from a file enables large files (not in the first > >> version probably) and other interesting use cases. > > EZ> What other cases? Large files is only theoretically useful, since > EZ> generally Emacs cannot do useful things on files larger than > EZ> most-positive-fixnum, and on 64-bit machines that is far enough to not > EZ> care. > > I think anything over 1 MB is pretty big. Not for Emacs. 1MB is actually pretty small, and shouldn't even bother us. A system that cannot spare 1MB is already in trouble. > There also pipes (pretty easy to fit the file model) How do you fit a pipe into the (file "FOO") model? > and network streams (probably a separate spec). Well, this part of the discussion was specifically about the (file "FOO") specs, so additional specs are a separate discussion. OTOH, all of these are readable into a buffer, so the buffer model could easily cover them all, no? > EZ> I think we need to weigh flexibility against the complexity, and find > EZ> the optimal balance. So making the interfaces too complicated for use > EZ> cases that will happen only very rarely, if at all, should be avoided. > > I agree in general, BUT these are not end-user APIs. They are for > application developers. They have to be flexible so we don't have to > bolt-on these things later. They have to be flexible enough, but not more flexible. We are talking about where to draw the line. > EZ> The data will always leave traces, because doing the above involves > EZ> reallocation of memory, so you are likely to leave traces in the page > EZ> file and in memory. But I don't think you can avoid that, whatever > EZ> you do: as long as data needs to be read into memory to process it, it > EZ> will always leave traces. > > Would you agree the tight loop that overwrites the read block will leave > fewer traces and offer fewer exposure opportunities? I don't know, I'm not a specialist on how these usage patterns affect VM and swap. Maybe you are right. > So how about a compromise for now: I can leave the `(file "foo")' > capability out. I'll adjust the docs to remove mentions of it. Then, > after the main patch is done, I can propose a followup patch to > implement `(file "foo")' and we can decide if it's good or bad. > > That will get the GnuTLS API integration working, and we can have a > separate discussion about `(file "foo")' later. Lars, Eli, would that be > acceptable? I think this should be fine, thanks.