On Wed, Jun 27, 2018 at 07:39:53PM +0100, Ramsay Jones wrote:
> Since commit ed8b10f631 ("fsck: check .gitmodules content", 2018-05-02),
> fsck will issue an error message for '.gitmodules' content that cannot
> be parsed correctly. This is the case, even when the corresponding blob
> object has been included on the skiplist. For example, using the cgit
> repository, we see the following:
>
> $ git fsck
> Checking object directories: 100% (256/256), done.
> error: bad config line 5 in blob .gitmodules
> error in blob 51dd1eff1edc663674df9ab85d2786a40f7ae3a5: gitmodulesParse: could not parse gitmodules blob
> Checking objects: 100% (6626/6626), done.
> $
>
> $ git config fsck.skiplist '.git/skip'
> $ echo 51dd1eff1edc663674df9ab85d2786a40f7ae3a5 >.git/skip
> $
>
> $ git fsck
> Checking object directories: 100% (256/256), done.
> error: bad config line 5 in blob .gitmodules
> Checking objects: 100% (6626/6626), done.
> $
>
> Note that the error message issued by the config parser is still
> present, despite adding the object-id of the blob to the skiplist.
>
> One solution would be to provide a means of suppressing the messages
> issued by the config parser. However, given that (logically) we are
> asking fsck to ignore this object, a simpler approach is to just not
> call the config parser if the object is to be skipped. Add a check to
> the 'fsck_blob()' processing function, to determine if the object is
> on the skiplist and, if so, exit the function early.
Yeah, this solution seems sensible. Given that we would never report any
error for that blob, there is no point in even looking at it. I wonder
if we ought to do the same for other types, too. Is there any point in
opening a tree that is in the skiplist?
> I noticed recently that the 'cgit.git' repo was complaining when
> doing an 'git fsck' ...
>
> Note that 'cgit' had a '.gitmodules' file and a 'submodule.sh'
> script back in 2007, which had nothing to do with the current
> git submodule facilities, ... ;-)
Yikes. I worried about that sort of regression when adding the
.gitmodules checks. But this _is_ a pretty unique case: somebody was
implementing their own version of submodules (pre-git-submodule) and
decided to use the same name. So I'm not sure if this is a sign that we
need to think through the regression, or a sign that it really is rare.
One thing we could do is turn the parse failure into a noop. The main
point of the check is to protect people against the malicious
.gitmodules bug. If the file can't be parsed, then it also can't be an
attack vector (assuming the parser used for the fsck check and the
parser used by the victim behave identically).
That wouldn't help with your stray message, of course, but it would
eliminate the need to deal with the skiplist here (and skiplists aren't
always easy to do -- for instance, pushing up a non-fork of cgit to
GitHub would now be rejected because of this old file, and you'd have to
contact support to resolve it).
> I just remembered that I had intended to review the name of the
> function that this patch introduces before sending, but totally
> forgot! :(
>
> [Hmm, 'to_be_skipped' -> object_to_be_skipped, object_on_skiplist,
> etc., ... suggestions welcome!]
The current name is OK to be, but object_on_skiplist() also seems quite
obvious.
-Peff
