Re: Unsafe file variables...

[David Kastrup <dak@gnu.org>]

Stefan Monnier <monnier@iro.umontreal.ca> 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