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: Thu, 20 Apr 2017 16:24:33 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87inlyrfni.fsf@lifelogs.com> References: <83o9xjn06c.fsf@gnu.org> <87shmeb5ln.fsf_-_@lifelogs.com> <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> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1492719896 26450 195.159.176.226 (20 Apr 2017 20:24:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 20 Apr 2017 20:24:56 +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 Thu Apr 20 22:24:51 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 1d1IdF-0006iC-Kq for ged-emacs-devel@m.gmane.org; Thu, 20 Apr 2017 22:24:49 +0200 Original-Received: from localhost ([::1]:55833 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d1IdL-0006U8-Bj for ged-emacs-devel@m.gmane.org; Thu, 20 Apr 2017 16:24:55 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43041) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d1IdF-0006Tw-G7 for emacs-devel@gnu.org; Thu, 20 Apr 2017 16:24:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d1IdA-0007mB-Ne for emacs-devel@gnu.org; Thu, 20 Apr 2017 16:24:49 -0400 Original-Received: from [195.159.176.226] (port=33164 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1d1IdA-0007lR-GO for emacs-devel@gnu.org; Thu, 20 Apr 2017 16:24:44 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1d1Id0-0006Nr-L9 for emacs-devel@gnu.org; Thu, 20 Apr 2017 22:24:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 76 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:9hIfYC6rNOwtDcHKowqhhgaxvbM= 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:214158 Archived-At: On Thu, 20 Apr 2017 22:38:05 +0300 Eli Zaretskii wrote: >> On Wed, 19 Apr 2017 18:45:40 +0300 Eli Zaretskii wrote: EZ> Not sure what you mean. I just did "git pull", and your branch's NEWS EZ> doesn't mention the manual section where this is described. Something EZ> like "See the node 'FOO' in the ELisp manual for more details." Am I EZ> blind? Oh! I see now. I thought there was some special formatting in NEWS to link to nodes. I've now done as you suggested. Incidentally it would be nice if NEWS (Outline mode) supported clickable links to the manuals like "(elisp) Formatting Strings" or (info "(elisp) Formatting Strings") or something else. Right now it's a bit awkward. EZ> Something like this at the beginning of the node: EZ> All of the functions described here accept argument lists of the EZ> form @code{(BUFFER-OR-STRING START END CODING-SYSTEM NOERROR)}, EZ> where BUFFER-OR-STRING ... OK, but I want to link to that from the C function docs too, since they also will reference that format. Would I link to the manual node? Is that OK for C functions, which are kind of standalone as far as docs go? EZ> I think (file "FOO") is the best. (I understand that the file will be EZ> submitted to GnuTLS functions for processing, is that right?) >> >> Since you and David agreed, I've made that the third allowed format. It >> errors out for now. Should I use an internal buffer (not in the visible >> list) and read into it, and then use the buffer data? Or should I use >> emacs_open() etc. and actually implement a raw file read operation, >> which should be a bit more secure and less subject to coding systems? EZ> I'm confused. I thought this form of an argument will cause the file EZ> name be passed to GnuTLS functions, and GnuTLS will then open the file EZ> and read its data. If that's not true, and Emacs needs to read the EZ> file anyway, then what's the purpose of having this form of the EZ> argument? How is it better than just reading the file into a EZ> temporary buffer and submitting the buffer to the function? I thought EZ> you wanted to avoid having the file's contents in Emacs's memory for EZ> security reasons. Sorry for the confusion; let me explain better. extract_data_from_object() is the API; any function that uses it (including secure_hash()) can benefit. I didn't want to write special cases in gnutls.c for file vs. buffer vs. string handling. So I said one approach is to use an internal (not visible to Lisp code) buffer and read the file into that, so the extract_data_from_object() function doesn't change much, and files reuse the buffer functionality. One advantage of that approach is that it would respect coding systems automatically, which seemed important earlier. But I should have been clear that it was just one possible approach. Then I listed another approach: to read the file directly with extract_data_from_object(). Based on your comments, and based on how we're sort of agreeing to limit the code to unibyte data, it's becoming clear that this is the better way. I also think it's more secure and less ambiguous. So I'll implement it. Thus extract_data_from_object() would allocate and read N bytes into a C memory buffer and pass that on, and the caller would have to free it. I'll see how that works out in code, but shouldn't be too bad. It will be a single place to review and fix, at least. I think I mentioned already that I am also considering how to specify the *output* of these functions better. It feels like it should parallel the same BUFFER-OR-STRING-OR-FILE structure so the functions can write to the desired place with minimal unintended visibility from Lisp. Thanks! Ted