unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Davis Herring <herring@lanl.gov>
Cc: emacs-devel@gnu.org
Subject: Re: The `risky-local-variable' blacklist
Date: Tue, 31 Aug 2004 15:42:03 -0600 (MDT)	[thread overview]
Message-ID: <Pine.LNX.4.44.0408311503520.31548-200000@x-mail.lanl.gov> (raw)
In-Reply-To: <m1wtzfctrb.fsf-monnier+emacs@gnu.org>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1946 bytes --]

> Actually, for mode-line variables, the situation is a bit more complex:
> the lack of "risky-local-variable" annotation was not introducing any kind
> of security hole because when we interpret a mode-line-string, we discard
> any "dangerous" element (such as "eval") unless the variable is marked as
> "risky".  I.e. either we check its safety via the "risky" annotation or we
> assume it's dangerous and we only use known-safe elements.
> 
> So the "risky" annotation was only added in order to enable potentially
> dangerous things like "eval" in that variable.

We may be speaking at cross-purposes, but are you sure about that?

$ emacs -q lvtest   #lvtest is attached to this message
M-: java-mode-abbrev-table RET
>> cheese
M-: java-mode-syntax-table RET
>> (((nil)))

Both those variables are set sans prompting with the default security
settings; of course, those variables (and the nonsense values I supply)  
are harmless, but other random variables with no `risky' or `safe' 
indications might not be.

I realize now that my example about timeclock is silly, because
`timeclock-mode-string' wasn't dangerous before and isn't now, since it
has never been included in `mode-line-format' except as a symbol, and
those are not evaluated twice (so as to execute a form set as its value).

However, this is itself worthy of note: gm, when he applied the
`risky-local-variable' brand, had mis-diagnosed the danger of that
variable.  All it takes is for one person (whose code, whether part of
Emacs or not, is used widely) to misdiagnose (or forget to diagnose) a
variable in the other direction, and trouble ensues.

So I believe my original statements about the (potential and extreme)
danger of such things -- and the necessity of improvement in their control
-- stand.

Davis Herring

-- 
This product is sold by volume, not by mass.  If it seems too dense or too 
sparse, it means mass-energy conversion has occurred during shipping.

[-- Attachment #2: Local Variables Test --]
[-- Type: TEXT/PLAIN, Size: 122 bytes --]

//-*- mode: Java; java-mode-abbrev-table : cheese -*-

//Local variables:
//java-mode-syntax-table: (((nil)))
//End:

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

  reply	other threads:[~2004-08-31 21:42 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-31  2:13 The `risky-local-variable' blacklist Davis Herring
2004-08-31 14:01 ` Stefan
2004-08-31 21:42   ` Davis Herring [this message]
2004-08-31 22:43     ` Stefan
2004-08-31 23:18       ` Davis Herring
2004-08-31 22:07 ` Richard Stallman
2004-08-31 23:07   ` Davis Herring
2004-09-01 19:24     ` Richard Stallman
2004-09-01  7:11   ` Kim F. Storm
2004-09-01 14:36     ` Stefan Monnier
2004-09-02  4:53     ` 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=Pine.LNX.4.44.0408311503520.31548-200000@x-mail.lanl.gov \
    --to=herring@lanl.gov \
    --cc=emacs-devel@gnu.org \
    /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).