bug#33264: Whitelist vc-follow-symlinks as a safe file variable

bug#33264: Whitelist vc-follow-symlinks as a safe file variable

[Eugene J.]

[-- Attachment #1: Type: text/plain, Size: 246 bytes --]

It is useful to have directory local `vc-follow-symlinks` with value `nil`
when you have to use symlink paths in a particular case while having it
`ask` or `t` as a default.
Marking the variable as  "safe file variable" will reduce the friction.

[-- Attachment #2: Type: text/html, Size: 407 bytes --]

bug#33264: Whitelist vc-follow-symlinks as a safe file variable

[Lars Ingebrigtsen]

"Eugene J." <w3techplayground@gmail.com> writes:

> It is useful to have directory local `vc-follow-symlinks` with value
> `nil` when you have to use symlink paths in a particular case while
> having it `ask` or `t` as a default.  Marking the variable as "safe
> file variable" will reduce the friction.

That seems reasonable.  Does anybody else object to marking this
variable as a safe file variable?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33264: Whitelist vc-follow-symlinks as a safe file variable

[Dmitry Gutov]

On 10.07.2019 16:11, Lars Ingebrigtsen wrote:
> "Eugene J." <w3techplayground@gmail.com> writes:
> 
>> It is useful to have directory local `vc-follow-symlinks` with value
>> `nil` when you have to use symlink paths in a particular case while
>> having it `ask` or `t` as a default.  Marking the variable as "safe
>> file variable" will reduce the friction.
> 
> That seems reasonable.  Does anybody else object to marking this
> variable as a safe file variable?

Sounds good to me.

I've tried to imagine a security issue stemming from it (e.g. linking to 
an external directory tree with its own dir-locals values, and then... 
what?), but didn't really come up with anything significant.

bug#33264: Whitelist vc-follow-symlinks as a safe file variable

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> I've tried to imagine a security issue stemming from it (e.g. linking
> to an external directory tree with its own dir-locals values, and
> then... what?), but didn't really come up with anything significant.

The doc string says that a nil is "dangerous", but doesn't say what the
danger is:

---
What to do if visiting a symbolic link to a file under version control.
Editing such a file through the link bypasses the version control system,
which is dangerous and probably not what you want.

If this variable is t, VC follows the link and visits the real file,
telling you about it in the echo area.  If it is ‘ask’, VC asks for
confirmation whether it should follow the link.  If nil, the link is
visited and a warning displayed.
---

I'm guessing it doesn't really mean "dangerous", but instead "not
optimal in most cases".

Anyway, what would the safe-local values be?  nil, t and ask or just
nil?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33264: Whitelist vc-follow-symlinks as a safe file variable

[Gustavo Barros]

Hi all,

On Mon, Jul 15 2019, Lars Ingebrigtsen wrote:

> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>> I've tried to imagine a security issue stemming from it (e.g. linking
>> to an external directory tree with its own dir-locals values, and
>> then... what?), but didn't really come up with anything significant.
>
> The doc string says that a nil is "dangerous", but doesn't say what the
> danger is:
>
> ---
> What to do if visiting a symbolic link to a file under version control.
> Editing such a file through the link bypasses the version control system,
> which is dangerous and probably not what you want.
>
> If this variable is t, VC follows the link and visits the real file,
> telling you about it in the echo area.  If it is ‘ask’, VC asks for
> confirmation whether it should follow the link.  If nil, the link is
> visited and a warning displayed.
> ---
>
> I'm guessing it doesn't really mean "dangerous", but instead "not
> optimal in most cases".


I’ve been following this thread and, if I may chime in, I think a good
reference in this respect is to note that `find-file-visit-truename` is
marked as a safe-local-variable in "files.el".

(Except that, as far as I can tell, it doesn’t work as a local
variable. See https://emacs.stackexchange.com/q/51495/18951. But that is
beyond the point here.)

Best regards,
Gustavo Barros.

bug#33264: Whitelist vc-follow-symlinks as a safe file variable

[Lars Ingebrigtsen]

Gustavo Barros <gusbrs.2016@gmail.com> writes:

> I’ve been following this thread and, if I may chime in, I think a good
> reference in this respect is to note that `find-file-visit-truename` is
> marked as a safe-local-variable in "files.el".

That's a good point.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33264: Whitelist vc-follow-symlinks as a safe file variable

[Dmitry Gutov]

On 15.07.2019 18:50, Lars Ingebrigtsen wrote:
> The doc string says that a nil is "dangerous", but doesn't say what the
> danger is

I don't understand the nature of the danger exactly as well, but I think 
the docstring means that the danger occurs when you edit _without_ 
following symlinks. Hence the default value (ask, then follow).

bug#33264: Whitelist vc-follow-symlinks as a safe file variable

[Lars Ingebrigtsen]

"Eugene J." <w3techplayground@gmail.com> writes:

> It is useful to have directory local `vc-follow-symlinks` with value `nil` when you
> have to use symlink paths in a particular case while having it `ask` or `t` as a
> default. 
> Marking the variable as  "safe file variable" will reduce the friction.

I've now marked the nil value as safe in Emacs 29.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no