mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <>
To: "Tessa L. H. Lovelace" <>
Cc:, Jeff King <>
Subject: Re: Using .gitignore symbolic links?
Date: Fri, 18 Jun 2021 13:15:46 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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

> 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

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

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...

  parent reply	other threads:[~2021-06-18 11:24 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-18  2:34 Using .gitignore symbolic links? Tessa L. H. Lovelace
2021-06-18  6:44 ` Robert Karszniewicz
2021-06-18 11:15 ` Ævar Arnfjörð Bjarmason [this message]
2021-06-18 12:55   ` Jeff King
2021-07-03 17:29   ` Tessa L.

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).