Dear Junio, Thanks for providing more insight! The error I'm seeing due to ".gitattributes" folder being present in the diff via the ".gitattributes/shared.gitattributes" file is the following: error in tree f8db7c96f9daf3ea8486804a3f717a807fc1a1d8: gitattributesBlob: non-blob found at .gitattributes I'm seeing this on both "git push" and "git fsck". Steps to reproduce: $ mkdir test $ cd test $ git init $ mkdir -p subdir/.gitattributes $ touch subdir/.gitattributes/some-file $ git add touch subdir/.gitattributes/some-file $ git commit -m "test" $ git fsck Checking object directories: 100% (256/256), done. error in tree 3666f1677ba5c7ec7e69544510a0d8b99a71774a: gitattributesBlob: non-blob found at .gitattributes git-push will give the same, at least when pushing to GitHub. Kind regards, Alexey > On 14 Jun 2024, at 17:35, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Alexey Pelykh <alexey.pelykh@xxxxxxxxx> writes: > >> I've stumbled upon a check that ensures that .gitmodules and >> .gitattributes must be blobs, > > Alexey, thanks for a report. > > For those who want to take a look, unfortunately Alexey does not > show any error message or describe the end-user visible effect that > the "check" caused, so there is a bit too little to go on. > >> yet while I get why they should not >> be e.g. a symlink, what's the downside of permitting (and ignoring >> for the actual purpose) e.g. .gitattributes folder? > > My knee-jerk reaction is that we probably can safely loosen by > ignoring non-blob .gitWHATEVER files, but security-minded folks may > be able to come up with some plausible attack scenarios if we did > so. > > Comments from those who have worked on transfer time and runtime > checks on these are highly appreciated. > > Having said that, the checks for .gitmodules and .gitattributes in > fsck.c first collect objects that tree entries with these names > point at into oidsets (this all happens in fsck.c:fsck_tree()), but > the actual check for these found objects are done only when they are > blobs. Only when we encounter a blob object, these oidsets are > looked at in fsck.c:fsck_blob(), and if it is .gitmodules its > contents inspected (and may result in a warning or an error). So > the "checks" Alexey reports may not be in the runtime or transfer > time checks done in fsck but something else. I dunno. > > Thanks. >
