From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Thibaut Verron Newsgroups: gmane.emacs.devel Subject: Precedence of criteria for file-local riskyness Date: Tue, 2 Jun 2020 17:35:25 +0200 Message-ID: Reply-To: thibaut.verron@gmail.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000b08e9f05a71ba98b" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="14720"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jun 02 17:38:40 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jg8zu-0003hw-Ck for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Jun 2020 17:38:38 +0200 Original-Received: from localhost ([::1]:48682 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jg8zt-0007vR-8T for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Jun 2020 11:38:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53024) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jg8x2-0005e8-40 for emacs-devel@gnu.org; Tue, 02 Jun 2020 11:35:40 -0400 Original-Received: from mail-wr1-x42f.google.com ([2a00:1450:4864:20::42f]:35695) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jg8x0-0004Hd-Tv for emacs-devel@gnu.org; Tue, 02 Jun 2020 11:35:39 -0400 Original-Received: by mail-wr1-x42f.google.com with SMTP id x14so3885973wrp.2 for ; Tue, 02 Jun 2020 08:35:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:from:date:message-id:subject:to; bh=wWO3BmJY85eWmUmuwZuTP+Ss3RuynLfHXDcn2izIRrI=; b=hQ+J7s9e/EFDDVUX9MlHDcV8yALUtWM5L2XQQPEnPnI+A1tL7HiD5BkLQmxgP0pGGJ kbBD/HThgO3vjLxRekkuW5LXX6mh7sdyZml9E5SSkX4bI+2Z1Aemj6USm7Riz1OP/gqL B4evQnJG3BStpEpEKRIDFFGUeBatWO+HsFXq+K+SewpufWxOiKxU772Dn/8AECquj/uV /N2y3UEKCQIojWj0Jx7P+AzSt9DK2fPpCNZq0SIhSzIMPND4AC4Z0Vkt5teHZQU5kYOL aovVPmM5iYLE4ddzILCZRioMpQ4oqiMuApOM2iIXIr04IdABGsVn5p7zxoOJG0vdImCU eSbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to; bh=wWO3BmJY85eWmUmuwZuTP+Ss3RuynLfHXDcn2izIRrI=; b=SG9CfdAcZg6/86a8i4wTOfgOxI8P8U2jOgZDWoT8QIWxxTO6TIyQC3ETNAIrOJqhHu XGkhOuV7YXM/iQ1IMj7QCDKY0xCDNcSJDJSLBBGY/merEv7X6ngOt26jnlXlZG8fuPG9 RenQbl9ODl9Yk8iwgf7qe4qk9CB8zm0Z0t2antuA1k3GNpzynUdBaSCJS2q0yzP0f/uc 0X1JPbfuUXxZesj/6TDy42WX7xfHSsrpKLA/ik87jxNvtEDnarToqJEiCDJbM65ctqXv /jBHGyJaDbrgOEjP6tcukRE4GY3um6GrihEcpHP2nHGiP7DryGG9h0qB5Q7113/Zc2lN 8iug== X-Gm-Message-State: AOAM533DVKV9fzfRtbZ/usBJkaMB2P2WVET0FQSbuW6phjuyJa2snGBn BTDSunlxe2NMe1j1Jex6qP8NrJ9Gh+FaQ2+chQEFfjOboaQGvg== X-Google-Smtp-Source: ABdhPJwgf7QWn4t1fh2TSG8wQ0cIczBszeZVvr/tJEZnO/sAFV905TBBRqzoE/m8iyR5/vLCKq4W6cmpTrlZPb1Rcik= X-Received: by 2002:a5d:5449:: with SMTP id w9mr27360856wrv.106.1591112136427; Tue, 02 Jun 2020 08:35:36 -0700 (PDT) Received-SPF: pass client-ip=2a00:1450:4864:20::42f; envelope-from=thibaut.verron@gmail.com; helo=mail-wr1-x42f.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:251758 Archived-At: --000000000000b08e9f05a71ba98b Content-Type: text/plain; charset="UTF-8" Hi, 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, Thibaut --000000000000b08e9f05a71ba98b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

According to the documentation, emacs cons= iders that if a variable name ends with -program, then it is probably risky= .=C2=A0

I guess that it is a fair assumption in ge= neral.
However, it seems that this assumption is taken even i= f:
- the variable declaration has a non-nil :safe property=C2= =A0
- the variable declaration has a nil :risky=C2=A0
<= br>
Is there a good reason for this?

Nai= vely, 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 sa= ys that a variable is not risky, even with a suspicious name, then their de= cision takes precedence.=C2=A0

It could also be us= eful if the reason why=C2=A0the variable is considered risky (suspicious na= me, explicitly marked as such, predicate not matching) could be added to th= e help message, for example so that users can make an educated decision whe= ther to bypass the security or not.

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


MWE: Consider the following code i= n a file:

=C2=A0 =C2=A0 (defun my-var-pr= ogram-pred (val)
=C2=A0 =C2=A0 =C2=A0 (memq val '("defau= lt value")))
=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 (de= fcustom my-var-program "default value"
=C2=A0 =C2=A0 = =C2=A0 "Program to be launched to use magma (usually magma)."
=C2=A0 =C2=A0 =C2=A0 :type 'string
=C2=A0 =C2=A0 =C2= =A0 :risky nil
=C2=A0 =C2=A0 =C2=A0 :safe 'my-var-program-pre= d)
=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 ;;;###autoload (pu= t 'my-var-program 'safe-local-variable 'my-var-program-pred)

=C2=A0 =C2=A0 ;; Local Variabl= es:
=C2=A0 =C2=A0 ;; my-var-program: "another value"
=C2=A0 =C2=A0 ;; End:

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


Best regards,
Thibaut

--000000000000b08e9f05a71ba98b--