From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Unsafe file variables... Date: 04 Apr 2004 16:49:48 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <87ekr3h4cn.fsf-monnier+emacs@alfajor.local> References: <87y8pbh5lk.fsf-monnier+emacs@alfajor.local> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1081112252 8651 80.91.224.253 (4 Apr 2004 20:57:32 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 4 Apr 2004 20:57:32 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sun Apr 04 22:57:25 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BAEgG-00086F-00 for ; Sun, 04 Apr 2004 22:57:24 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BAEgG-0001Um-00 for ; Sun, 04 Apr 2004 22:57:24 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BAEaX-00070p-Us for emacs-devel@quimby.gnus.org; Sun, 04 Apr 2004 16:51:29 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BAEaR-00070Z-Ar for emacs-devel@gnu.org; Sun, 04 Apr 2004 16:51:23 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BAEZv-0006uU-9h for emacs-devel@gnu.org; Sun, 04 Apr 2004 16:51:22 -0400 Original-Received: from [209.226.175.74] (helo=tomts20-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BAEYv-0006cw-Fp; Sun, 04 Apr 2004 16:49:49 -0400 Original-Received: from alfajor ([67.71.119.109]) by tomts20-srv.bellnexxia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040404204948.HLUF15811.tomts20-srv.bellnexxia.net@alfajor>; Sun, 4 Apr 2004 16:49:48 -0400 Original-Received: by alfajor (Postfix, from userid 1000) id 9807FD73C1; Sun, 4 Apr 2004 16:49:48 -0400 (EDT) Original-To: David Kastrup In-Reply-To: Original-Lines: 58 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:21246 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:21246 >> Think of it as "check whether a piece of code is signed" (the >> Microsoft notion of security) vs "check that the code type checks" >> (the Java notion of security). > Well, we already have determined that the variable _is_ unsafe to set. No, we have only determined that the variable is not always safe to set. That's very different. > But since there still is an imaginable reason for setting that > variable, the user gets the question. If you think that you can rule > out the desirability of not mechanically checkable code being run, > then that is the obvious way to go. But I don't see any sandbox > model for Elisp that would get us even half there. I don't understand what you're trying to say. >> Now in general it's clearly impossible to check any arbitrary piece >> of elisp code and give a good answer. But a good solution was >> proposed a while back here: add a customization variable that allows >> the user to specify a list of safe code which he's willing to eval >> in the future. > The list would have to get added to for each change. Yes. Just like it would have to be re-signed for each change. > In short, the user would have to manually judge the potential of the > danger of such settings for each change, and record his decision. Exactly. Just as is the case right now, except that he would get to record his decision so he won't be prompted over and over again in the future. > I was proposing a mechanism allowing delegation of such decisions to > a verified source the user has declared trustworthy. Yes, that's what I understood and what I consider as undesirable. > This is less safe than a qualified judgment of the user for himself > for every instance. _IF_ the user is capable of making a qualified > judgment. The same "IF the user is capable of making a qualified judgment" applies to the authentication approach: the user has to assess the trustworthiness of the source instead of the safety of the code. Accepting a key does not just mean "I trust that Foo never intends harm", but rather "I trust that every person who will ever get access to Foo's private key will never intend harm". > I just noticed that I get frequently annoyed by such questions and was > trying to come up with a comparatively safe way to avoid them. My approach is much more lightweight and can probably be coded in 10 lines. I do believe in the "philosophical" arguments above, but ultimately the implementation simplicity is what I'd aim for. Stefan