Hi Joey,
On Wed, 22 May 2024, Joey Hess wrote:
> 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.
> 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.
> + 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
