From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: GNU Emacs-libnettle-libhogweed integration patch v1 Date: Mon, 07 Oct 2013 00:02:37 -0400 Message-ID: References: <877gdqrc9u.fsf@flea.lifelogs.com> <87mwmmp05f.fsf@flea.lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1381118574 26388 80.91.229.3 (7 Oct 2013 04:02:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 7 Oct 2013 04:02:54 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 07 06:02:57 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VT225-00005Z-Bv for ged-emacs-devel@m.gmane.org; Mon, 07 Oct 2013 06:02:57 +0200 Original-Received: from localhost ([::1]:57269 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VT225-0006GD-10 for ged-emacs-devel@m.gmane.org; Mon, 07 Oct 2013 00:02:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43843) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VT21u-00067V-20 for emacs-devel@gnu.org; Mon, 07 Oct 2013 00:02:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VT21m-0001SC-Mm for emacs-devel@gnu.org; Mon, 07 Oct 2013 00:02:45 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:5718) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VT21m-0001S6-Hn for emacs-devel@gnu.org; Mon, 07 Oct 2013 00:02:38 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFHO+K8t/2dsb2JhbABEvw4Xc4IeAQEEAVYoCws0EhQYDYhCBsEtjWGDKQOkeoFegxM X-IPAS-Result: Av4EABK/CFHO+K8t/2dsb2JhbABEvw4Xc4IeAQEEAVYoCws0EhQYDYhCBsEtjWGDKQOkeoFegxM X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="34902532" Original-Received: from 206-248-175-45.dsl.teksavvy.com (HELO fmsmemgm.homelinux.net) ([206.248.175.45]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 06 Oct 2013 23:59:01 -0400 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 92B5BAE4CB; Mon, 7 Oct 2013 00:02:37 -0400 (EDT) In-Reply-To: <87mwmmp05f.fsf@flea.lifelogs.com> (Ted Zlatanov's message of "Sun, 06 Oct 2013 17:19:56 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:163935 Archived-At: > I certainly hope others see the utility of the work, especially so I can > implement OpenPGP support and avoid depending on the external GnuPG > binary for verifying package signatures. Yes, we've been through this in the past, and my position is still the same: I don't want to have to maintain an OpenPGP implementation in Emacs when we can outsource this maintenance to the GPG guys. We have enough trouble with code we can't outsource. Especially for code that touches security and cryptography where it's all too easy to make very subtle mistakes. IOW I wouldn't oppose bindings to a libgpg on the same grounds (tho such bindings probably wouldn't be very useful if all they do is replace a dependency on "external gpg executable" with a dependency on libgpg, where libgpg is not more likely to be installed than gpg). > It would also let me implement binary signatures of Emacs data (to > make sure it's not corrupted) I don't know what that is. > and true secrets (Lisp data strings that can't be decoded without the > right key). We try our best to make sure Emacs doesn't crash on the user. That's a very far cry from making Emacs code sufficiently secure that the data we keep in Emacs heap can be considered secret. And even besides latent security holes, I don't even know how you intend to make such a "secret" work (who'd be prevented from seeing/using it?). IOW it's much too hypothetical to justify accepting such bindings. > the Nettle patch is accepted, so it would have been nice to state your > opposal earlier. I certainly stated my intentions clearly. I stated it many times already in earlier discussions. Stefan