From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: package.el + DVCS for security and convenience Date: Thu, 27 Dec 2012 12:06:39 +0900 Message-ID: <87d2xwtcqo.fsf@uwakimon.sk.tsukuba.ac.jp> References: <8738zf70ep.fsf@riseup.net> <871uejlbm1.fsf@lifelogs.com> <87obhmzl2f.fsf@bzg.ath.cx> <20121222141742.7494b429fe36e5ccef50cf6f@gmail.com> <87d2y2w9j5.fsf@uwakimon.sk.tsukuba.ac.jp> <87wqwas0gr.fsf@bzg.ath.cx> <87d2y2p6d7.fsf@bzg.ath.cx> <87sj6xg9p2.fsf_-_@lifelogs.com> <87k3s78hsc.fsf@lifelogs.com> <874njbuen3.fsf@uwakimon.sk.tsukuba.ac.jp> <87bodg7v1t.fsf@lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1356577616 23840 80.91.229.3 (27 Dec 2012 03:06:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 27 Dec 2012 03:06:56 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 27 04:07:12 2012 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 1To3oH-000740-CC for ged-emacs-devel@m.gmane.org; Thu, 27 Dec 2012 04:07:05 +0100 Original-Received: from localhost ([::1]:38823 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1To3o2-0003jH-8D for ged-emacs-devel@m.gmane.org; Wed, 26 Dec 2012 22:06:50 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:59814) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1To3nx-0003j5-LQ for emacs-devel@gnu.org; Wed, 26 Dec 2012 22:06:48 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1To3nu-0004ZW-LY for emacs-devel@gnu.org; Wed, 26 Dec 2012 22:06:45 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:52288) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1To3nu-0004Z0-4G for emacs-devel@gnu.org; Wed, 26 Dec 2012 22:06:42 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 636139708F8 for ; Thu, 27 Dec 2012 12:06:39 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 2AF8F11F810; Thu, 27 Dec 2012 12:06:39 +0900 (JST) In-Reply-To: <87bodg7v1t.fsf@lifelogs.com> X-Mailer: VM undefined under 21.5 (beta32) "habanero" b0d40183ac79 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 130.158.97.224 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:155921 Archived-At: Ted Zlatanov writes: > The same logic applies to using GnuTLS inside Emacs vs. gnutls-cli > externally. I don't buy either argument. Indeed I did apply it there, and good for you. But that's *just* you. > Emacs is a platform and must make intelligent choices to protect > the security of its users. Yes. And one of those intelligent choices is to do well what Emacs can do well, and leave up to the users what they can probably do equally well, or mess up the best Emacs can do if they choose to be security-unconscious. The problem is that Emacs's security not only has to be better than the users' to be useful, it has to be *much* better. As soon as *one* application used by *millions* becomes responsible for security in some area, it becomes not a security shield, but a vector for mass attack -- cracked once, it exposes enough users to interest the black hat pros.[1] Worse (IMO), that vector exposes security-conscientious users to an "inside job". Thing is, viewed from that point of view, I don't buy you (or Paul Eggert, for that matter) as an authority on security good enough, or available enough (which might extend to making security your day-in, day-out contribution to Emacs) to make such decisions *for all Emacs users*. You could sell me on that point, though. *You haven't tried.* That is what worries me. I know, from embarrassing personal experience, that smart people trying to be secure can be exploited. It's not a question of your skills as a programmer, it's your attitude as a "security officer" that doesn't thrill me. > Depending on external binaries has always been a security issue that > shifts the burden to the user and the system administrator. That article "the" is a nice try, but I don't admit your sentence's implicit assumption that the burden is monolithic. Every complex system is going to have many security weaknesses, and the user is *always* going to be #1 on that list (even if his name is "Bond. James Bond."). There are many security burdens, and the implementation of package checking is just one of them. There is a well-known "law"[2] in social science called the "principle of second best," which may be phrased "stronger may be weaker [because of interactions with the rest of the system]". (An accurate phrasing would be "independent component-wise improvements may interact to produce degraded system performance.") It surely applies to security. > (Also see my earlier suggestions about providing secure data > storage at the C level, so Emacs is not as vulnerable to core dumps > to find user passwords and other secrets. There are many areas to > improve.) The question is, which ones can and should Emacs take responsibility for? Providing secure storage is surely one of them, because AFAIK users can't do that themselves with an external tool. Some people who do security as their "job number one" (ie, the folks who wrote the GPG manual, I am not one of them and I don't know how widespread their opinion is) seem to be saying that implementing the OpenPGP protocol is not, because GPG provides a perfectly good tool to do the job. I'm not welded to my "don't do this" position; I just think there are a lot of things you could better do, and that it's a good idea to limit the attack surface that *your* work presents. If you use GPG cli tools, that surface is limited to the path(s) from the socket talking to ELPA to the call-process call to gpg2. If you do signature verification yourself, you *also* have to audit that implementation. I think Emacs would be better off if you go after the "only Emacs itself can do it" tasks first. > The OpenPGP protocol is described in http://tools.ietf.org/html/rfc4880 > and thus fairly standard. Verifying a signature, in particular, does > not require implementing the full protocol, No, it's not difficult to implement. But quis custodiet: what makes you think your implementation itself won't be vulnerable to attacks, many of which may not be under your implementation's control? Again, I'm not saying "DON'T EVEN THINK of doing it", I'm suggesting that you lack the skills and the humility to do a *sufficiently good job for all Emacs users* because implementing *in* Emacs increases the required level of quality by *orders of magnitude* as compared to borrowing an existing, external implementation proved secure by long experience. I suspect you lack the time to acquire the skills *and* apply them *as required by security applications*, and you don't seem to have a clue about the hubris. Obviously, I could be wrong -- I *know* that *I* don't have the skills required to judge whether your implementation is secure or not. I'd just be a lot happier for Emacs if you seemed more aware of the complexity and burden of the task you propose to undertake. And it wouldn't hurt if, say, Paul Eggert were to speak up and say he promises to do thorough reviews[2], and you could cite an authority saying that the concerns of the GPG manual author are valid but exaggerated, and .... Footnotes: [1] Not to mention that given the number of times GNU/FSF sites have been hacked, some of the black hats seem to have it in for GNU. One suspects that a Day Zero attack on ELPA might be quite a trophy in some circles. [2] It's a systematic contruction of counterexamples to monotonicity rather than a positive law of nonmonotonicity. [3] Which he would probably do anyway, of course (I know that he has a more than passing interest in encryption, and I wouldn't be surprised if he has qualifications and experience in other areas of security as well). The point is that I think that Emacs deserves an *explicit* commitment to do this well, and in the case of security, that surely means *explicit* commitments to independent reviews, etc.