>> +(put 'elisp-flymake-byte-compile-load-path 'safe-local-variable
>> + (lambda (x) (and (listp x) (catch 'tag
>> + (dolist (path x t) (unless (stringp path)
>> + (throw 'tag nil)))))))
AFAICS the above tests whether the value is valid, not whether it is safe.
This should probably be a risky-local-variable, like load-path is.
The default "." seems actively dangerous, in much the same way as having
"." in a shell's PATH is.
Glenn,
I'm aware of the difference between valid and safe. One of us is missing something:
1. The new variable I introduce only has any effect when flymake-mode is enabled in elisp buffers.
2. Currently, flymake-mode is pretty unsafe since it byte-compiles the file which can run arbitrary compile-time code in that file.
3. It doesn't make sense for an attacker to use the new variable as a file-local var since it's much easier to add some eval-when-compile instead to the file itself.
4. The only attack I could envision is to set the var in
dir-locals.el, assuming the attacker had access to that file and not the other .el files that live in that directory.
As i tried to explain, I added the validity spec to the variable, precisely because I thought 4 was pretty far-fetched, and couldn't find any other plausible scenario. Can you?
João