[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
request to reconsider libnettle/libhogweed (was: How to ship native modu
From: |
Ted Zlatanov |
Subject: |
request to reconsider libnettle/libhogweed (was: How to ship native modules?) |
Date: |
Thu, 02 Mar 2017 09:59:59 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) |
On Tue, 21 Feb 2017 12:06:40 -0800 John Wiegley <address@hidden> wrote:
JW> Sure, I'm fine with [GSSAPI] being in core.
Hi, John, Eli, and everyone else. It's been a few years since I've
brought up the libnettle/libhogweed topic and we've had lots of change
in the C core and in our community.
Since it's apparently OK to add the GSS/Kerberos linkage to the core, I
want to ask again that the libnettle/libhogweed crypto functions be
allowed in the core, for the following reasons:
* they are more *generally* useful than GSS and will enable future
development in many directions. (I'm not saying GSS is not useful,
just that it's a more specific tool that serves a narrow purpose.)
* we already link to GnuTLS, which means those C functions are available
already. So this is not going to require much extra C code, just some
work to expose the C functions. My original patch, now many years old,
can probably be adapted or rewritten pretty easily. Most of it was
tests. Keeping up to date is similarly easy as long as users keep up
to date with GnuTLS. Note also that on the Lisp side, no low-level
crypto code will be written or maintained, we're only exposing
libraries that are maintained and reviewed by an existing large
community.
* recall that Stefan, the maintainer at the time, asked me to push for a
module approach with the understanding that the crypto module would be
distributed to let users and packages access those functions. We now
have a module system, but there has been no support or interest in
implementing a module *distribution* system that would allow users to
access those cryptographic functions with a stock distribution of
Emacs. Instead all the comments have been that it's a hard problem and
the Emacs developers would rather not deal with it. Where the comments
have suggested a solution, it has been "let them run make" which
rhymes with "let them eat cake."
* personally, I would rather make the core more functional out of the
box, so my proposal is to go back to the original C patch instead of
inventing a module distribution system. (A module distribution system
may yet make sense, and I have nothing against it, but I don't want to
wait more years for it or invent it.)
Thank you for your consideration.
Ted
- request to reconsider libnettle/libhogweed (was: How to ship native modules?),
Ted Zlatanov <=
Re: request to reconsider libnettle/libhogweed, Paul Eggert, 2017/03/02