Re: Non-blob .gitmodules and .gitattributes

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 14, 2024, 15:35 UTC
Message-ID: <xmqqbk43ilk3.fsf@gitster.g>
In-Reply-To: <4F3AD9A8-DA3E-43E2-BF9A-9D7458EED7EA@gmail.com>

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.