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

Previous Next

Full log

Message #43 received at 61901 <at> debbugs.gnu.org (full text, mbox):

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

> From: Antero Mejr <antero <at> mailbox.org>
> Cc: 61901 <at> debbugs.gnu.org
> Date: Thu, 11 May 2023 17:49:50 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > 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.

We already have all that in file-equal-p.  We should just use is
there.

Previous Next

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