Re: Non-blob .gitmodules and .gitattributes

[Alexey Pelykh <alexey.pelykh@gmail.com>]

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@pobox.com> wrote:
> 
> Alexey Pelykh <alexey.pelykh@gmail.com> 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.
>