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

OK, whatever: we agree.

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

Hmmm... I guess you're considering a very different usage pattern
from mine.  In my estimate of how things play out in practice, there is
the following:
1 - "usafe file vars" are not very frequent.
2 - they're not very varied either (because you'll open the same file many
    times, because the same setting will be used in several files, because
    it's used for things tat don't change much, ...).
3 - they're mostly used "by the author, for the author".
4 - they'll be signed by the author of the file in 99% of the cases.

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

For the case with signature, the author (which I expect to be the main user)
will have to do it, just the same.

> Well, it would be nice if I could decide "don't prompt me
> particularly for every change Stefan Monnier makes".

The problem is:
- are there going to be more pieces of code or more authors?
  You assume there'll be many more different pieces of code than authors,
  whereas I expect that there'll be about as many of each.

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

Sure.

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

I'm not opposing it, but I just don't think it's worth the trouble.
I think that `safe-local-eval-forms' (which I didn't notice had been
installed: cool) covers the need just fine for now (after all, we've had
always/never/prompt as the only method until very recently and I haven't
seen too many people complain).
I'd personally be interested as well in improving the automatic safety
checking so that prompting (and safe-local-eval-forms or sign-checking)
is needed less often.  But I've seen so few concrete and useful examples
of local vars, that it's difficult to know what to look at.

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

As mentioned above, I don't expect this to be very different in practice,
because most users will typically only ever get one piece of code to check
from any given author.  So they'll spend their time downloading public keys
and blessing them as trusted.  The scheme would maybe work of we could have
delegation such that RMS could bless your key as trustworthy and users
wouldn't have to, but that gets even more Big-Brotherish.

> And for many persons, trusting a person is an easier decision than
> trusting their judgment about a particular piece of potentially
> malicious code.

Easier maybe.  Better, I don't know.

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

And in his behavior in case of threats, depression, whatever.

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

Indeed.  Feel free to submit a patch.  And explain the kind of scenarios
you're imagining where a given author will write many such pieces of "unafe
file vars" and many users will want to use them.
Note that as a package author you are already trusted: you can create
a foo-mode function in AUCTeX and then just add a `mode: foo' entry
that will call the function, assuming it to be safe.


        Stefan