From: Luc Teirlinck <teirllm@dms.auburn.edu>
Cc: ken.manheimer@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org
Subject: Re: allout patch - more safe-local-variables, plus autoloads
Date: Wed, 19 Apr 2006 21:47:56 -0500 (CDT) [thread overview]
Message-ID: <200604200247.k3K2luJe016211@jane.dms.auburn.edu> (raw)
In-Reply-To: <E1FWJyL-0006Gn-IV@fencepost.gnu.org> (message from Richard Stallman on Wed, 19 Apr 2006 17:12:25 -0400)
Richard Stallman wrote (in response to Stefan Monnier):
If we disallow t and want a quick&dirty replacement predicate
for boolean values, we can either introduce booleanp (seems
like a good predicate to have around anyway) or just use symbolp.
symbolp is not correct; a boolean variable can have any Lisp object
as its value. If booleanp is mean to mean "is t or nil", that
would also be incorrect.
This is not about correctness, but about safety. Any non-nil value
for a minor mode variable is "correct", in that it is equivalent with
t, but why would anybody actually _want_ to use any other value than t
in a local variables list. If anybody actually did it, I would want
to see it because it would make me suspicious.
Currently, putting:
;;; no-byte-compile: (funcall (lambda () ... some hairy code ... ))
in a local variables list gets evaluated without asking, because
`no-byte-compile' has a safe-local-variable property of t. The "hairy
code" is not tested for safety at all. I checked this using obviously
unsafe code.
But if you got asked, would you really just immediately respond yes
without taking a look at that lambda expression, because that lambda
expression is equivalent with t anyway and hence perfectly "correct"?
If I really believed that the above code currently could be exploited
in harmful way, I would not be posting it publicly. For it to do
harm, no-byte-compile should be evaluated twice as in
(eval no-byte-compile), although there are other ways to produce
repeated evaluation than using eval. If somebody tried to get
(eval no-byte-compile) or similar evaluated elsewhere in the local
variables list, then the user would get asked about _that_.
(Otherwise this would be a serious bug).
But as we keep increasing the number of boolean variables with a
safe-local-variable property of t, then the probability increases that
by some freakish accident one of these boolean variables gets
evaluated twice in the Emacs source code. This would be a bug,
because the boolean variable can take any value and hence should not
be evaluated twice. But in practice, one always uses t or nil as
values, so the bug could easily escape detection for a long time
(unlike similar bugs for variables that are normally lists, where the
double evaluation would immediately throw an error, exposing the bug).
The above scenario might not seem excessively likely but why take _any_
risk, since there is no good reason to use non-nil values other than t
for boolean variables in a local variables list?
I do believe that for variables of type DEFVAR_BOOL all values are
completely safe, since they get immediately translated to nil or t anyway.
Sincerely,
Luc.
next prev parent reply other threads:[~2006-04-20 2:47 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-17 19:11 allout patch - more safe-local-variables, plus autoloads Ken Manheimer
2006-04-18 12:57 ` Richard Stallman
2006-04-18 13:18 ` Stefan Monnier
2006-04-19 4:17 ` Richard Stallman
2006-04-19 4:39 ` Stefan Monnier
2006-04-19 21:12 ` Richard Stallman
2006-04-20 2:47 ` Luc Teirlinck [this message]
2006-04-20 17:34 ` Stefan Monnier
2006-04-21 13:07 ` Richard Stallman
2006-04-21 15:02 ` Ken Manheimer
2006-04-21 15:09 ` David Kastrup
2006-04-21 15:39 ` Ken Manheimer
2006-04-21 17:15 ` Stefan Monnier
2006-04-24 21:19 ` Ken Manheimer
2006-04-19 23:08 ` Ken Manheimer
2006-04-20 10:35 ` Richard Stallman
2006-04-20 18:49 ` autoloads for safe-local-variables (was: allout patch - more safe-local-variables, plus autoloads) Reiner Steib
2006-04-20 19:52 ` autoloads for safe-local-variables (was: allout patch - moresafe-local-variables, " Stuart D. Herring
2006-04-21 13:07 ` autoloads for safe-local-variables (was: allout patch - more safe-local-variables, " Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200604200247.k3K2luJe016211@jane.dms.auburn.edu \
--to=teirllm@dms.auburn.edu \
--cc=emacs-devel@gnu.org \
--cc=ken.manheimer@gmail.com \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).