From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: request to reconsider libnettle/libhogweed (was: How to ship native modules?) Date: Thu, 02 Mar 2017 09:59:59 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87bmtjiv0w.fsf_-_@lifelogs.com> References: <83a89gq3us.fsf@gnu.org> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1488466894 17703 195.159.176.226 (2 Mar 2017 15:01:34 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 2 Mar 2017 15:01:34 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 02 16:01:24 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cjSEL-0003DK-Lg for ged-emacs-devel@m.gmane.org; Thu, 02 Mar 2017 16:01:21 +0100 Original-Received: from localhost ([::1]:52813 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cjSER-0008Bf-QD for ged-emacs-devel@m.gmane.org; Thu, 02 Mar 2017 10:01:27 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45336) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cjSDK-0007yJ-Au for emacs-devel@gnu.org; Thu, 02 Mar 2017 10:00:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cjSDG-0001eU-Eb for emacs-devel@gnu.org; Thu, 02 Mar 2017 10:00:18 -0500 Original-Received: from [195.159.176.226] (port=37698 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cjSDG-0001dH-8z for emacs-devel@gnu.org; Thu, 02 Mar 2017 10:00:14 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1cjSD2-0003vN-5V for emacs-devel@gnu.org; Thu, 02 Mar 2017 16:00:00 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 45 Original-X-Complaints-To: usenet@blaine.gmane.org X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never Cancel-Lock: sha1:VZh7oZReBK5rj4pzPx/0I0hBxdc= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:212707 Archived-At: On Tue, 21 Feb 2017 12:06:40 -0800 John Wiegley 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