[Top][All Lists]

[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

* 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]