Re: Non-blob .gitmodules and .gitattributes

From: Alexey Pelykh <alexey.pelykh@gmail.com>
Date: Jun 14, 2024, 15:43 UTC
Message-ID: <8E37AD78-C480-4838-9F69-3E7FC209A9FC@gmail.com>
In-Reply-To: <xmqqbk43ilk3.fsf@gitster.g>

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

Show 37 quoted lines

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