[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Precedence of criteria for file-local riskyness

From: Thibaut Verron
Subject: Precedence of criteria for file-local riskyness
Date: Tue, 2 Jun 2020 17:35:25 +0200


According to the documentation, emacs considers that if a variable name ends with -program, then it is probably risky. 

I guess that it is a fair assumption in general.
However, it seems that this assumption is taken even if:
- the variable declaration has a non-nil :safe property 
- the variable declaration has a nil :risky 

Is there a good reason for this?

Naively, I would expect that if a variable can have some safe values, then it is reasonable to give the user the choice to save other safe values (and it can always be overridden with :risky t). And that if the package author says that a variable is not risky, even with a suspicious name, then their decision takes precedence. 

It could also be useful if the reason why the variable is considered risky (suspicious name, explicitly marked as such, predicate not matching) could be added to the help message, for example so that users can make an educated decision whether to bypass the security or not.

For the anecdote, in my specific use-case, all of this was even more surprising because emacs was repeatedly querying me whether the default value for the variable was safe. Of course adding an adequate :safe setting fixed that, and this situation probably doesn't happen often enough to be worth generalizing.

MWE: Consider the following code in a file:

    (defun my-var-program-pred (val)
      (memq val '("default value")))
    (defcustom my-var-program "default value"
      "Program to be launched to use magma (usually magma)."
      :type 'string
      :risky nil
      :safe 'my-var-program-pred)
    ;;;###autoload (put 'my-var-program 'safe-local-variable 'my-var-program-pred)

    ;; Local Variables:
    ;; my-var-program: "another value"
    ;; End:

Eval it with or without compiling, then revert the buffer and see that the "always mark as safe" option is not proposed.

Best regards,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]