GNU bug report logs -
#33264
Whitelist vc-follow-symlinks as a safe file variable
Previous Next
Reported by: "Eugene J." <w3techplayground <at> gmail.com>
Date: Mon, 5 Nov 2018 02:56:01 UTC
Severity: wishlist
Fixed in version 29.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 33264 in the body.
You can then email your comments to 33264 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33264
; Package
emacs
.
(Mon, 05 Nov 2018 02:56:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Eugene J." <w3techplayground <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Mon, 05 Nov 2018 02:56:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33264
; Package
emacs
.
(Wed, 10 Jul 2019 13:13:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 33264 <at> debbugs.gnu.org (full text, mbox):
"Eugene J." <w3techplayground <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33264
; Package
emacs
.
(Mon, 15 Jul 2019 15:31:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 33264 <at> debbugs.gnu.org (full text, mbox):
On 10.07.2019 16:11, Lars Ingebrigtsen wrote:
> "Eugene J." <w3techplayground <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33264
; Package
emacs
.
(Mon, 15 Jul 2019 15:51:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 33264 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33264
; Package
emacs
.
(Mon, 15 Jul 2019 16:24:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 33264 <at> debbugs.gnu.org (full text, mbox):
Hi all,
On Mon, Jul 15 2019, Lars Ingebrigtsen wrote:
> Dmitry Gutov <dgutov <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33264
; Package
emacs
.
(Mon, 15 Jul 2019 17:35:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 33264 <at> debbugs.gnu.org (full text, mbox):
Gustavo Barros <gusbrs.2016 <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33264
; Package
emacs
.
(Mon, 15 Jul 2019 18:22:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 33264 <at> debbugs.gnu.org (full text, mbox):
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).
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33264
; Package
emacs
.
(Sat, 22 Jan 2022 15:46:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 33264 <at> debbugs.gnu.org (full text, mbox):
"Eugene J." <w3techplayground <at> 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
bug marked as fixed in version 29.1, send any further explanations to
33264 <at> debbugs.gnu.org and "Eugene J." <w3techplayground <at> gmail.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sat, 22 Jan 2022 15:46:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 20 Feb 2022 12:24:09 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 137 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.