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: Thu, 20 Apr 2017 19:24:14 +0300 Message-ID: <83mvbbavyp.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> <83bmrscvdb.fsf@gnu.org> <871ssos8jp.fsf@lifelogs.com> <83y3uwb995.fsf@gnu.org> <83wpafbyk6.fsf@gnu.org> <83o9vraxow.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1492705434 23976 195.159.176.226 (20 Apr 2017 16:23:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 20 Apr 2017 16:23:54 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 20 18:23:49 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 1d1Ery-0005xb-Q5 for ged-emacs-devel@m.gmane.org; Thu, 20 Apr 2017 18:23:46 +0200 Original-Received: from localhost ([::1]:54994 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d1Es1-0004Ya-Md for ged-emacs-devel@m.gmane.org; Thu, 20 Apr 2017 12:23:49 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39218) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d1Err-0004Wn-Ik for emacs-devel@gnu.org; Thu, 20 Apr 2017 12:23:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d1Ern-0008JB-5J for emacs-devel@gnu.org; Thu, 20 Apr 2017 12:23:39 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38069) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d1Ern-0008J5-23; Thu, 20 Apr 2017 12:23:35 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3420 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1d1Erm-0001x0-6C; Thu, 20 Apr 2017 12:23:34 -0400 In-reply-to: (message from Lars Ingebrigtsen on Thu, 20 Apr 2017 17:59:51 +0200) 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:214149 Archived-At: > From: Lars Ingebrigtsen > Cc: Stefan Monnier , emacs-devel@gnu.org > Date: Thu, 20 Apr 2017 17:59:51 +0200 > > These are encryption primitives. Stuffing code that guesses What I Mean > into these primitives doesn't seem like the most productive way to > proceed. If somebody later wants to add a DWIM framework on top of > these primitives (to, say, automatically encrypt everything that Emacs > saves), that's a different thing. > > But the primitives themselves should, in my opinion, be functional and > predictable: You give them explicit inputs and you always get the same > result back. You can have predictability if you bind coding-system-for-write to whatever you want. Just like you do with file and process I/O. > Encryption is also often used in conjunction with various protocols, and > (as opposed to saving files locally) the local user's preferences are > irrelevant to how the octets are supposed to be encoded on the wire. How is this different from sending the stiff unencrypted via the same protocols? Once again, please tell why the considerations you raise do NOT apply to write-region, insert-file-contents, send-string etc., because if they do apply, we already have very reasonable solutions for them, which are well-tested by time and many users. In the I/O department, experience shows that most users and programmers don't want/need this level of control, so the heuristics that does TRT without burdening users/programmers is a Good Thing.