From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Unsafe file variables... Date: 05 Apr 2004 04:14:36 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <87y8pbh5lk.fsf-monnier+emacs@alfajor.local> <87ekr3h4cn.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 1081131445 6554 80.91.224.253 (5 Apr 2004 02:17:25 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 5 Apr 2004 02:17:25 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon Apr 05 04:17:18 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 1BAJfq-0002s9-00 for ; Mon, 05 Apr 2004 04:17:18 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BAJfp-0005cK-00 for ; Mon, 05 Apr 2004 04:17:17 +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 1BAJeH-0002AC-Ep for emacs-devel@quimby.gnus.org; Sun, 04 Apr 2004 22:15:41 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BAJdp-00020h-PC for emacs-devel@gnu.org; Sun, 04 Apr 2004 22:15:13 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BAJdI-0001iR-Cy for emacs-devel@gnu.org; Sun, 04 Apr 2004 22:15:11 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BAJdI-0001iK-4O for emacs-devel@gnu.org; Sun, 04 Apr 2004 22:14:40 -0400 Original-Received: from fencepost.gnu.org ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.24) id 1BAJdB-0004en-5G; Sun, 04 Apr 2004 22:14:33 -0400 Original-To: Stefan Monnier In-Reply-To: <87ekr3h4cn.fsf-monnier+emacs@alfajor.local> User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 Original-Lines: 135 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:21265 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:21265 Stefan Monnier writes: > >> 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. In each particular case where we would want to consult a signature, we have determined that we don't know whether setting the variable could be dangerous. That means we have determined that it is unsafe to set. That's the premise. We would not be in the situation to pop up a question if that was not the case. The signature is not interesting for any other case. > > 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. That the safeness of setting an Elisp variable can't be always decided automatically and by the computer just by looking at the code. In the end, someone will have to look at the code and decide whether it is safe. This will be the responsibility of the user. Now he may have a list as follows: 1. Emacs says setting the variable that way is safe. The user probably trusts Emacs enough to not bother further. He can set his variables to express this belief. 2. Whoever put that stuff in the file probably feels this is safe. That says pretty much nothing. Who was it? Probably many persons. 3. The file claims that Stefan Monnier says this is safe. Well, if malicious code was in there, it would probably claim whatever it wanted. 4. Stefan Monnier has checked the setting, declared it as safe and signed it. Now the user has the choice to configure _once_ "if it's good enough for Stefan Monnier, it is good enough for me." And he can be reasonably sure that indeed Stefan Monnier and not somebody else has checked this setting and declared it safe. > >> 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. No. Each change that would trigger such a message needs to be signed. But if I told my system once "If Stefan Monnier has signed a change, don't ask", then while you need to sign each such change you do, but a hundred users need to tell their Emacs only once that they trust your judgment. > > 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. You are confusing the scenarios. This sentence is for the case without signatures. It is the case I want to avoid. > 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. Well, it would be nice if I could decide "don't prompt me particularly for every change Stefan Monnier makes". If I decide that I don't want to trust Stefan Monnier blindly, deciding whether to answer such a prompt might benefit from the information "My GPG system says that this change, purported to be called safe from Stefan Monnier, indeed has been called safe by him". > > 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. Well, if that's what you understood, I can't follow your reasoning. And I fail to see where you explain why it would be undesirable. When I put forward this proposal, I already said that there might be good reasons against it. I just fail to see what you would consider a good reason. > > 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. Right. But he has to do this only once, not every time. And for many persons, trusting a person is an easier decision than trusting their judgment about a particular piece of potentially malicious 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". Right. It trusts the person's judgment in his key management as well. > > 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. But your approach does not allow to factor "xxx has declared this change safe" into either the user's or Emacs' decision. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum