From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: Wherein I argue for the inclusion of libnettle in Emacs 24.5 Date: Thu, 06 Feb 2014 10:54:33 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87d2j0ck3q.fsf@lifelogs.com> References: <87ha8f3jt1.fsf@building.gnus.org> <87ppn2qz0f.fsf@building.gnus.org> <87y51qcace.fsf@lifelogs.com> <874n4e3rkm.fsf@uwakimon.sk.tsukuba.ac.jp> <87txcdd6d0.fsf@lifelogs.com> <87wqh8n877.fsf@uwakimon.sk.tsukuba.ac.jp> <87lhxocvfq.fsf@lifelogs.com> <87sirwmgd9.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1391702100 28295 80.91.229.3 (6 Feb 2014 15:55:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Feb 2014 15:55:00 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 06 16:55:03 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 1WBRI6-0006Kv-5D for ged-emacs-devel@m.gmane.org; Thu, 06 Feb 2014 16:55:02 +0100 Original-Received: from localhost ([::1]:37119 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WBRI5-0000ti-Pw for ged-emacs-devel@m.gmane.org; Thu, 06 Feb 2014 10:55:01 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52286) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WBRHx-0000qc-J0 for emacs-devel@gnu.org; Thu, 06 Feb 2014 10:54:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WBRHr-0008V9-JX for emacs-devel@gnu.org; Thu, 06 Feb 2014 10:54:53 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:33796) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WBRHr-0008Uz-DA for emacs-devel@gnu.org; Thu, 06 Feb 2014 10:54:47 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WBRHo-000655-T3 for emacs-devel@gnu.org; Thu, 06 Feb 2014 16:54:44 +0100 Original-Received: from c-98-229-61-72.hsd1.ma.comcast.net ([98.229.61.72]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 06 Feb 2014 16:54:44 +0100 Original-Received: from tzz by c-98-229-61-72.hsd1.ma.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 06 Feb 2014 16:54:44 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 64 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-98-229-61-72.hsd1.ma.comcast.net 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 User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) Cancel-Lock: sha1:gVeJX6op44hL3rXbms9wDb0bTDY= 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:169441 Archived-At: On Fri, 07 Feb 2014 00:05:06 +0900 "Stephen J. Turnbull" wrote: SJT> Ted Zlatanov writes: >> Inside Emacs, there would have to be a passphrase popup in the >> minibuffer or elsewhere that can't be faked from ELisp but must >> come from the "secure core." SJT> Ted, there is no "secure core" in an Emacs Lisp application. That was SJT> the main point of the defadvice. If *your* Lisp program can invoke a SJT> password popup, so can *my* sleazebag defadvice. Yes, that would be an attack target internally, obviously. But a) I was originally talking about how calling out to external programs makes it hard to tell if the popup is authentic or not[1]; and b) this needs work and discussion, but I think it's a valuable use case. What do you think happens when you open a .gpg file using GnuPG externally, even disregarding the OS channels traveled? That data is certainly not safe from defadvice. I try to protect passwords in auth-source by wrapping them in closures; EPA/EPG simply throws the data into a buffer. This is *not* saying the EPA/EPG design is bad, only that Emacs as a whole could use a way to hide "data not intended for direct user inspection" better, and provide for a "tainting" trace of data (to use the Perl term). For special files like authinfo.gpg, you certainly don't need the whole file in memory just to grab one line. SJT> Not at all. The presence of those primitives is an attractive SJT> nuisance, encouraging security neophytes to roll-their-own authn/authz/ SJT> crypto systems. If you want horror stories, there are plenty archived SJT> at the RISKS forum and on CERT. Statistically speaking, availability SJT> of these functions will mean somebody *will* get screwed by a self- SJT> injected security bug. >> >> I can't debate what could happen, that's what "hypothetical" means. SJT> Security is all about what *could* happen if you're not careful. If SJT> you aren't already thinking carefully about that, I don't understand SJT> why you're doing this! OK then, let's hypothesize. I don't think the presence of these primitives will make the situation worse by flooding us with badly implemented crypto. I may be wrong, but it just doesn't seem likely. One of the things you learn from RISKS is that generally, things tend to work out all right as long as the source code is open and vulnerabilities are disclosed quickly. Realistically speaking, attacks against Emacs are extremely unlikely unless specific people are targeted. The user population is too small. We also don't generally have anything all that secret or precious stored in Emacs (except RMS, who has a million Bitcoins and is the real Satoshi Nakamoto, you heard it here first). So I think comparing the risks of what I'm proposing to, say, bank databases or airplane software is a bit ambitious. Ted [1] One of my first tasks as a sysadmin, many years ago on AIX, was to stop some attackers with internal access. They had set up a login system that decrypted some special files with a password and wiped them clean on logout. Their encryption password, for technical and practical reasons, was the fastest way to stop them completely. So I simply made a prompt that looked the same as the normal one, grabbed their password, and told them "wrong password, reenter please." It then wiped itself out of their login files.