Re: libnettle/libhogweed WIP

[Ted Zlatanov]

On Wed, 17 May 2017 19:22:13 +0300 Eli Zaretskii <address@hidden> wrote: 

>> From: Ted Zlatanov <address@hidden>
>> Date: Mon, 15 May 2017 17:55:34 -0400
>> 
>> On Fri, 21 Apr 2017 09:14:02 +0300 Eli Zaretskii <address@hidden> 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