From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.devel Subject: Wherein I argue for the inclusion of libnettle in Emacs 24.5 Date: Mon, 03 Feb 2014 14:36:42 -0800 Organization: Programmerer Ingebrigtsen Message-ID: <87ha8f3jt1.fsf@building.gnus.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1391467078 23909 80.91.229.3 (3 Feb 2014 22:37:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 3 Feb 2014 22:37:58 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 03 23:38:06 2014 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 1WAS9V-0005VX-FT for ged-emacs-devel@m.gmane.org; Mon, 03 Feb 2014 23:38:05 +0100 Original-Received: from localhost ([::1]:49894 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WAS9V-0003xp-4Z for ged-emacs-devel@m.gmane.org; Mon, 03 Feb 2014 17:38:05 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56011) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WAS9M-0003vw-Ih for emacs-devel@gnu.org; Mon, 03 Feb 2014 17:38:02 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WAS9G-00056D-RB for emacs-devel@gnu.org; Mon, 03 Feb 2014 17:37:56 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:56854) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WAS9G-000565-Jx for emacs-devel@gnu.org; Mon, 03 Feb 2014 17:37:50 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WAS9F-0005NK-6v for emacs-devel@gnu.org; Mon, 03 Feb 2014 23:37:49 +0100 Original-Received: from 204.14.154.233 ([204.14.154.233]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 03 Feb 2014 23:37:49 +0100 Original-Received: from larsi by 204.14.154.233 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 03 Feb 2014 23:37:49 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 104 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 204.14.154.233 Mail-Copies-To: never User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3.50 (gnu/linux) Cancel-Lock: sha1:RP7z6MKJrsqKRPIP0plZriblDlY= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:169370 Archived-At: Ted posted a patch to give Emacs native encryption support a few months back: http://permalink.gmane.org/gmane.comp.encryption.nettle.bugs/736 It was rejected because Stefan thinks that we should wait until we have FFI support in Emacs, and it should be implemented that way. I'm going to argue that 1) I don't think we should wait, and 2) FFI isn't that great, anyway. We Shouldn't Wait ================= Using encryption from Emacs is pretty awkward now. GnuPG 2.0 has shifted to a model where the applications themselves can't feed any passwords into the GnuPG programs -- they always ask for the passwords themselves, or rely on the user having started a gpg daemon that will handle the password storage. I've started writing a new thing for Gnus that is basically Dropbox + newsrc storage via IMAP: http://lars.ingebrigtsen.no/2014/02/01/emacs-cloud/ The idea is that you should be able to say `M-x gnus' on a brand new laptop, answer a few questions, and then your entire setup is replicated. And you can move back and forth between different machines pretty seamlessly. This means pushing data that might be sensitive over the network, and storing it in IMAP folders. So we need encryption. Since we're pushing updates pretty regularly, we need to encrypt smaller chunks. Asking for a password every single time would make this impossible to use. If we required the user to run a gpg daemon, that would help, but it's awkward to have to do that, and it's not supported on all OS-es. If Emacs had native support for encryption, this would be trivial to handle. And in these days of greater security vigilance (not only the NSA stuff, but an ever-larger number of data breaches), not providing proper encryption to these data stores would be irresponsible, I think. Of course, the Emacs Cloud stuff isn't the only thing that could do with encryption. The original use case Ted had -- storing credentials in a more opaque manner -- is still as relevant as ever. And I'd just like to remind everybody here that adding encryption support won't bring in any further library dependencies. This is all already brought into the Emacs builds by the gnutls support. So it's all "for free". FFI Isn't That Great Anyway =========================== My experiences with FFI comes from using it under proprietary Common Lisp environments. There it's absolutely necessary. But it's necessary because it's a proprietary environment. If we're in the Free World, as we definitely are in Emacs, linking with the libraries using the normal ways and means are always superior. If you're interfacing with a library like crypt(3), FFI is fine. You have a function that takes a couple of strings, and you get one string back. All FFI converters do that fine. But, unfortunately, that's often all they do. Real C libraries often have gnarly error reporting conventions, callbacks, weird data structures, etc, etc. In my Common Lisp experiences, I've sometimes found that I can either write a 200 line monstrosity in the FFI framework, or I can write a seven line C program that calls the library it's supposed to be called. So Stefan suggest just making these C shims be part of the FFI thing, and we'll just distribute packages with some C code included. Which would then have to be compiled. It's a possibly solution, but many systems don't ship with C compilers, so this would drastically reduce the uptake of the packages. There are other problems with allowing "third party" binary packages into Emacs, too. We'll get further incomprehensible segfaults reported, which we probably can't do much about. Emacs doesn't have a formal stable "internal ABI", anyway. Experiences from other projects that have tried to allow binary plugins (like gcc) seem to show that that's not the way to go, either. If you allow binary modules to be inserted, they aren't that useful unless you lock down your internal ABIs. And I think that would be a hindrance to further Emacs development. So, To Sum Up ============= 1) Carthage should be destroyed 2) Emacs should support encryption as soon as possible to best handle the security needs of our users 4) FFI is nice for proprietary products, but sub-optimal for free software -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/