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: Tue, 08 Jan 2013 10:44:36 +0900 Message-ID: <87y5g4a1ob.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> <87ehi65uv4.fsf@lifelogs.com> <87hamxndc7.fsf@lifelogs.com> <87y5g8n4y1.fsf@lifelogs.com> <87lic8b9ai.fsf@uwakimon.sk.tsukuba.ac.jp> <87zk0mktir.fsf@lifelogs.com> <87bod1bvhg.fsf@uwakimon.sk.tsukuba.ac.jp> <877gnpkq1u.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 1357609483 18904 80.91.229.3 (8 Jan 2013 01:44:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Jan 2013 01:44:43 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 08 02:45:01 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 1TsOFQ-0006iG-5o for ged-emacs-devel@m.gmane.org; Tue, 08 Jan 2013 02:45:00 +0100 Original-Received: from localhost ([::1]:43940 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TsOFA-0007nP-CW for ged-emacs-devel@m.gmane.org; Mon, 07 Jan 2013 20:44:44 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:49138) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TsOF7-0007nK-DG for emacs-devel@gnu.org; Mon, 07 Jan 2013 20:44:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TsOF5-0005hg-Jp for emacs-devel@gnu.org; Mon, 07 Jan 2013 20:44:41 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:45610) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TsOF5-0005ay-1y for emacs-devel@gnu.org; Mon, 07 Jan 2013 20:44:39 -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 8C980970900 for ; Tue, 8 Jan 2013 10:44:36 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 51ACE1A30DD; Tue, 8 Jan 2013 10:44:36 +0900 (JST) In-Reply-To: <877gnpkq1u.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:156126 Archived-At: Ted Zlatanov writes: > On Mon, 07 Jan 2013 11:03:07 +0900 "Stephen J. Turnbull" wrote: > > SJT> Ted Zlatanov writes: > >> I'm actually suggesting that the GNU ELPA maintainers (note the "GNU > >> ELPA" part here, this is not any ELPA maintainer) should review and sign > >> *every* commit to the GNU ELPA. > > SJT> I have no idea what you think you're proposing. > > I hope that doesn't make my proposal less ideal. If I'm not alone, it certainly does. > SJT> Security reviews are expensive; I doubt you'll have anybody willing > SJT> to maintain GNU ELPA after a couple of months of that, unless you > SJT> pay handsomely, or you enlist a maintainer per package or so to > SJT> reduce the burden on individual maintainers to a manageable level. > > Trust is expensive. You're scaring me again. Trust is cheap, but risky. That's not the same. > The alternative is to say "trust this code, though we don't know > what it is." Your use of the unique quantifier is once again inappropriate. "We" does not have to be an undifferentiated blob; it can be personalized. You could, for example, have each volunteer provide a separate signature as they review the code. More reviews, more trust -- maybe, unless more reviews means each one is less thorough. Identification of the reviewer means trust can be a function of the reviewer. Authors don't make the best reviewers, but they do know the code, and an author signature is a certificate of authenticity. In general, having signatures that identify (a) the stage at which the code was signed and (b) the authority doing the signing are useful inputs to (some) users' trust functions. I don't know if it's worth it, but it certainly proves that your strawman is not the only alternative. > That's the current state of affairs. And, to a large extent, it will be the state of affairs under your proposal, unless your "FSF and GNU volunteers" do a certain amount of work on *every* commit to GNU ELPA. The only thing that signing (by itself) proves is provenance. If it's signed, you know the signer touched it. That is valuable information, even though it doesn't prove the code is clean. If you actually do reasonably thorough reviews, though, you will end up with a large backlog of pending commits unless you have a lot of volunteers. (At least one hopes that there will be a lot of code committed to GNU ELPA, right?) > There is certainly review of code that goes into GNU Emacs itself. A > security exploit would be caught quickly (I hope, based on previous > cases like the file-local variable exploits). Uh, yeah ... maybe. AFAICS much code that goes into Emacs doesn't get reviewed by someone other than the author/committer, most code review that is done for Emacs itself is hardly security-oriented, and the exploits were caught after the fact in all cases I know of.[1] I think you vastly underestimate the cost to reviewers and authors of doing a sufficiently good job to justify trusting the code at a significantly higher level than currently. (Authors will have to rework features rejected for security of implementation reasons, and it would be quite painful to have a whole feature rejected for security reasons). > The GNU ELPA, being enabled by default, should be treated the same. But > because it's a network resource, we must use signatures to indicate > files in the GNU ELPA can be trusted, since we don't package the GNU > ELPA with Emacs itself. No, what signatures are for is to authenticate the file, ie, to prove that this is indeed a true GNU ELPA file and not a counterfeit. Trust will be allocated to *code received from* GNU ELPA on the basis of the review policy and its quality of implementation, not simply because it's signed. > In other words, we're building a web of trust around GNU Emacs because > we want to be able to install parts of it (hosted in the GNU ELPA) > optionally and over the network. That's where "trust" matters. Why do you think anybody in this thread doesn't understand that? > I never said it would be cheap or easy to do this. True. *I* *did* say that it would be expensive. Very. What worries me is that you make statements like > But I think the FSF and GNU volunteers can handle the task, and I > firmly believe reviewing Emacs Lisp code is much easier than C, > C++, Perl, etc. code. without offer any cost estimate (eg, # of commits per month, amount of volunteer time per month, amount of time spent doing background checks on volunteers, amount of time spent making sure that volunteers aren't conspiring with Untrustworthy Authors, etc). Nor do I see why reviewing Emacs Lisp code is *much* easier. No buffer overflows, it's true, but magic execution (aka hooks) are all over the place. Anything that reads a file using find-file (let alone `load') can execute arbitrary Lisp, in fact, arbitrary executables using call-process via hooks. > I'll volunteer my own time for these reviews, unless of course you > or others are opposed because it would make me a "security tzar" or > because it's felt I'm unqualified. I don't think you're unqualified. I do wonder why you think you're *more* qualified than package authors. AFAIK you're not currently a GNU ELPA maintainer? > As I said, the alternative is the current "just trust whatever we > put online" model, which is certainly cheap to run. And you're wrong about that. People *do* just trust, by and large, but that is *not* their only option, even under current conditions. In fact, as far as I know many people are *currently* exercising a different option by only trusting a few packages that are put online at ELPA. > SJT> The obvious candidates for the latter are the authors. > > No. Yes. I wrote "candidate", not "automatic pass". *Many* authors (ie, committers, since it has to be committed to GNU ELPA) are well-known. True, it would be a bad idea to allow any random patch author to certify their work, but if it has passed through the affected package's community's review and been signed by a well-known package author (ie, its maintainer), I can't see any claim that a review by an unspecified "volunteer" who may not know anything about the package is more trustworthy. No? > SJT> If they are not security reviews, what's the point of reviewing at > SJT> all? You just want signed commits, verifying that the commit was > SJT> actually received at the GNU ELPA. AFAICS this can be done by a bot, > SJT> which checks the authors' signatures on the commits. > > No. No what? That's a moderately complex piece of logic you're denying. Steve Footnotes: [1] That could be because Emacs has a security cabal and they don't discuss their reviews on this list.