GnuTLS C support for nsm.el

GnuTLS C support for nsm.el

[Ted Zlatanov]

Since 3.0.13, GnuTLS has gnutls_verify_stored_pubkey() and
gnutls_store_pubkey() according to
https://www.gnutls.org/manual/html_node/Certificate-verification.html
which can replace a good chunk of the code in nsm.el and move it down
the stack.

The UI is similar to the typical SSH hostkey acceptance. By default
these use ~/.gnutls/known_hosts but Emacs could override the backend
storage function to use the ~/.emacs.d/network-security.data file.

I am neutral about this, but wanted to bring it up for discussion. Does
anyone think this GnuTLS facility is valuable enough to start using it,
or should we keep nsm.el the way it is, Emacs Lisp only? Lars?

Thanks
Ted

Re: GnuTLS C support for nsm.el

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> The UI is similar to the typical SSH hostkey acceptance. By default
> these use ~/.gnutls/known_hosts but Emacs could override the backend
> storage function to use the ~/.emacs.d/network-security.data file.
>
> I am neutral about this, but wanted to bring it up for discussion. Does
> anyone think this GnuTLS facility is valuable enough to start using it,
> or should we keep nsm.el the way it is, Emacs Lisp only? Lars?

I think it would be confusing to put some of this functionality in
GnuTLS-specific files and some in NSM-specific files, from a user's
point of view.  And since NSM has more functionality, I think it wins.
:-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: GnuTLS C support for nsm.el

[Ted Zlatanov]

On Tue, 15 Nov 2016 00:19:41 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> I am neutral about this, but wanted to bring it up for discussion. Does
>> anyone think this GnuTLS facility is valuable enough to start using it,
>> or should we keep nsm.el the way it is, Emacs Lisp only? Lars?

LI> I think it would be confusing to put some of this functionality in
LI> GnuTLS-specific files and some in NSM-specific files, from a user's
LI> point of view.  And since NSM has more functionality, I think it wins.
LI> :-)

OK, thanks for looking!

Ted