Re: Unsafe file variables...

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> 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