GNU bug report logs - #61901
30.0.50; [PATCH] Add permanently-enabled-local-variable-dirs variable.

Previous Next

Full log

View this message in rfc822 format

From: Antero Mejr <antero <at> mailbox.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61901 <at> debbugs.gnu.org
Subject: bug#61901: 30.0.50; [PATCH v3] Add safe-local-variable-directories variable.
Date: Thu, 11 May 2023 17:49:50 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> diff --git a/doc/lispref/variables.texi b/doc/lispref/variables.texi
>> index b3a8cd8110c..28deddf985d 100644
>> --- a/doc/lispref/variables.texi
>> +++ b/doc/lispref/variables.texi
>> @@ -1986,7 +1986,7 @@ fully-expanded absolute file names that end in a
>> directory separator
>>  character.  They may also be remote directories if the variable
>>  @code{enable-remote-dir-locals} is set non-@code{nil}.  Directories in
>>  this list are matched case-sensitively, even if the filesystem is
>> -case-sensitive.
>> +case-insensitive.
>>  @end defvar
>
> This actually means that I misunderstood the code.  Now that I see the
> truth, why is it a good idea to compare directories case-sensitively
> when the filesystem is not?  That's not something users will expect.

What if a directory's case sensitivity changes so that it previously did
not match, but now does? This could happen with Windows per-directory
case sensitivity modifications, mounted disks, or remote paths.

To accurately assess if a directory name matches with possible
case-sensitivity, the process would be:
1. check the case-sensitivity of the filesystem
2. If case insensitive, check the case-sensitivity of each subdirectory
(using Windows queryCaseSensitiveInfo if applicable)
3. map over the components of the directory name, checking each subdirectory
with the correct case-sensitivity setting

That logic would be difficult for users to reason about, so for features
with security considerations like this I think it's better to err on the
side of safety and simplicity even if the behavior is stricter than
expected.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.