Re: Using .gitignore symbolic links?

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Jun 18, 2021, 11:15 UTC
Message-ID: <87o8c34dq6.fsf@evledraar.gmail.com>
In-Reply-To: <1623983680.3494.0@smtp.dreamhost.com>

On Thu, Jun 17 2021, Tessa L. H. Lovelace wrote:

Show 37 quoted lines

> The recent release candidate of Git (v2.32.0) hit my OS this week, and
> it included a line () on symbolic links for several specific files are 
> now ignored.
>
> Thank you for putting the changelogs in an accessible location,
> knowing that this was a known breaking change was useful in debugging
> why my workflows stopped working.
>
> I have two concerns.
>
> First, the error thrown is
>
>> "warning: unable to access '.gitignore': Too many levels of symbolic
>   links",
>
> ,,,which does not accurately represent what is happening.
>
> I spent a bit of time convinced that I'd broken something with the
> symbolic links during setup, and an error such as "symbolic linking no 
> longer allowed for 'filename'." would make more sense, given the
> change under discussion eliminates *any* use of symbolic links.
>
>
> Secondly, and more personally important to me, a system administrator:
> My repositories use symbolic links to allow a single .gitignore file
> to define my folder structure, allowing me to avoid hardcoding the 
> repo-specific folder paths into my configs.
>
> Is there a flag to disable this new behavior?
>
> If not, this change means I need to update dozens of files, duplicates
> all, or completely rewrite my .gitignore files to have shyteloads of 
> arbitrary file paths in them, which I'd rather not do.
>
> Also, is there a justification for forcing this as the on-update
> default new behavior, when a user-querying behavior (such as with 'git 
> pull' defaults as they've changed recently) exists?

[CC-ing Jeff]

Breaking this was intentional, see https://github.com/git/git/commit/2ef579e261

That doesn't mean we can't take it back.

As discussed by Robert's reply and in that commit there's the workaround of .git/info/exclude and the core.excludesFile.

However, we realize that sucks for many users. Let's say you have a script to clone a "tree" of repositories similar to but not using git-submodule (or they live side-by-side), such a thing won't Just Work anymore.

At the end of the day there's an inherent conflict here between security and convenience. We really want a repository to be safe to just "git clone", i.e. we don't set up any hooks, execute code etc.; these gitattributes and gitignore issues were on edges of that.

We can make it work as before, but it gets hard to distinguish the gitignore you mean, from a gitignore that's pointing to /dev/urandom (annoying), or to some crafted out-of-tree thing that'll cause an overflow in the parser and an RCE.

Any way out of that that's configurable is going to be be the same opt-in problem as core.excludesFile is now.

So I'd think our options are basically:

 1) Do nothing, it sucks for some people (like you) but we think it's worth it

 2) Some DWYM middle ground, e.g. we could discover if the link points
    to another git repo, and only trust it then, or if it's in the
    user's $HOME or whatever.

 3) Bring back the old behavior, it was more of a "while we're at it for
    gitattributes..." fix than something specifically a problem with
    gitignore, the RCE threat is a hypothetical, and we can more easily
    audit/be confident in the gitignore parser, probably...