From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jonathan Yavner Newsgroups: gmane.emacs.devel Subject: Re: risky local variable mechanism Date: Sat, 11 Feb 2006 15:27:31 -0500 Message-ID: <200602111527.31031.jyavner@member.fsf.org> References: <200602101313.13663.jyavner@member.fsf.org> <87accxlt6z.fsf@stupidchicken.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1139704240 19487 80.91.229.2 (12 Feb 2006 00:30:40 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 12 Feb 2006 00:30:40 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 12 01:30:39 2006 Return-path: Envelope-to: ged-emacs-devel@gmane.org Original-Received: from mail-relay.eunet.no ([193.71.71.242]) by ciao.gmane.org with esmtp (Exim 4.43) id 1F858E-0000wN-0p for ged-emacs-devel@gmane.org; Sun, 12 Feb 2006 01:30:35 +0100 Original-Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by mail-relay.eunet.no (8.13.1/8.13.1/GN) with ESMTP id k1C0UPpk057779 for ; Sun, 12 Feb 2006 01:30:25 +0100 (CET) (envelope-from emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org) Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F854S-0005jx-FH for ged-emacs-devel@m.gmane.org; Sat, 11 Feb 2006 19:26:32 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1F82PQ-0001yJ-OJ for emacs-devel@gnu.org; Sat, 11 Feb 2006 16:36:01 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1F81vW-000195-Bh for emacs-devel@gnu.org; Sat, 11 Feb 2006 16:05:08 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F81LD-0004s0-Mg for emacs-devel@gnu.org; Sat, 11 Feb 2006 15:27:35 -0500 Original-Received: from [204.127.200.84] (helo=sccrmhc14.comcast.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1F81PI-000486-0C for emacs-devel@gnu.org; Sat, 11 Feb 2006 15:31:48 -0500 Original-Received: from [192.168.0.254] (c-68-45-81-14.hsd1.nj.comcast.net[68.45.81.14]) by comcast.net (sccrmhc14) with ESMTP id <20060211202734014002cov4e>; Sat, 11 Feb 2006 20:27:35 +0000 Original-To: Chong Yidong , Luc Teirlinck User-Agent: KMail/1.6.2 In-Reply-To: <87accxlt6z.fsf@stupidchicken.com> Content-Disposition: inline X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:50374 Archived-At: Chong Yidong wrote: > One solution is to to keep `risky-local-variable-p' > around for unsafep.el to use, but not actually use it in > files.el---and just rely on the whitelist mechanism. I don't think this is a good idea. `risky-local-variable-p' was invented five years ago precisely so that files.el and unsafep.el would use the same rules for deciding whether variables were safe. If files.el says a variable is unsafe but unsafep.el thinks it's safe, that is a security hole (a spreadhseet could be written that would tickle the unsafe variable). If files.el says a variable is safe but unsafep says it isn't, that will annoy the user (who will be required to approve the use of that variable every time he loads the spreadsheet). In general, lambdas are unsafe if unsafep says they are, so we could call it instead of arbitrarily declaring that all xxx-function variables are unsafe. If a variable can be nil, a number, or a lambda, we can use unsafep instead of arbitrarily rejecting all lambda cases. Luc Teirlinck wrote: > If the current risky-local-variable-p is too unreliable for > `enable-local-eval' to such a degree that an urgent fix is needed, is > it really reliable enough for unsafep? What exactly is the problem with the current system? Are there unsafe variables erroneously declared safe? Are there file-local variables with safe values erroneously declared unsafe? What is the minimum change needed to solve the current problem? > (risky-local-variable-p myvar nil) very well may return t, even though > assigning a value of nil may be perfectly safe (and probably is). Yeah, I don't like that, either. If a variable has some safe and some unsafe values, it seems likely that nil would be one of the safe ones. Changing this calling convention would break backward compatibility, although it doesn't *seem* like the function is used outside of files.el and unsafep.el. > I am not sure that Chong's patch should use risky-local-variable-p at > all. Again, if files.el and unsafep.el do not use the same mechanism, Emacs will have two definitions for the same concept ("safe variable") which will lead to either security holes or user annoyance.