Re: [PATCH 0/2] Revert defense-in-depth patches breaking Git LFS

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: May 27, 2024, 19:35 UTC
Message-ID: <fbb89826-0d83-d4f9-bab4-9fba69e0e22d@gmx.de>
In-Reply-To: <Zk2_mJpE7tJgqxSp@kitenet.net>

Hi Joey,

On Wed, 22 May 2024, Joey Hess wrote:

Show 9 quoted lines

> brian m. carlson wrote:
> > If these protections hadn't broken things, I'd agree that we should keep
> > them.  However, they have broken things and they've introduced a
> > serious regression breaking a major project, and we should revert them.
>
> More than one major project; they also broke git-annex in the case where
> a git-annex repository, which contains symlinks into
> .git/annex/objects/, is pushed to a bare repository with
> receive.fsckObjects set. (Gitlab is currently affected[1].)

This added fsck functionality was specifically marked as `WARN` instead of `ERROR`, though. So it should not have failed.

Show 8 quoted lines

> BTW, do I understand correctly that the defence in depth patch set was
> developed under embargo and has never been publically reviewed?
>
> Looking at commit a33fea0886cfa016d313d2bd66bdd08615bffbc9, I noticed
> that its PATH_MAX check is also dodgy due to that having values ranging
> from 260 (Windows) to 1024 (Freebsd) to 4096 (Linux), which means git
> repositories containing legitimate, working symlinks can now fail to be
> pushed depending on what OS happens to host a reciving bare repository.

Likewise, this fsck functionality was specifically marked as `WARN` instead of `ERROR`, to prevent exactly the issue you are seeing.

Are you saying that Gitlab is upgrading fsck warnings to errors? If so, I fear we need to ask Gitlab to stop doing that.

> +                               if (is_ntfs_dotgit(p))
>
> This means that symlinks to eg "git~1" are also warned about,
> which seems strange behavior on eg Linux.

Only until you realize that there are many cross-platform projects, and that Windows Subsystem for Linux is a thing.

> +                               backslash = memchr(p, '\\', slash - p);
>
> This and other backslash handling code for some reason is also run on
> linux, so a symlink to eg "ummmm\\git~1" is also warned about.

Right. As far as I can tell, there are very few Linux-only projects left, so this is in line with many (most?) projects being cross-platform.

Show 5 quoted lines

> +               if (!buf || size > PATH_MAX) {
>
> I suspect, but have not confirmed, that this is allows a symlink
> target 1 byte longer than the OS supports, because PATH_MAX includes
> a trailing NUL.

True. That condition is basically imitating the `size > ATTR_MAX_FILE_SIZE` one a couple of lines earlier, but it should be `>=` here because `PATH_MAX` is supposed to accommodate the trailing NUL.

Ciao, Johannes