Re: libnettle/libhogweed WIP

[Ted Zlatanov <tzz@lifelogs.com>]

On Thu, 20 Apr 2017 22:38:05 +0300 Eli Zaretskii <eliz@gnu.org> wrote: 

>> On Wed, 19 Apr 2017 18:45:40 +0300 Eli Zaretskii <eliz@gnu.org> 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