Subject: Re: Non-blob .gitmodules and .gitattributes

From: Junio C Hamano <[email-masked]>
Date: Fri, 14 Jun 2024 08:35:56 -0700

Alexey Pelykh <[email-masked]> 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.