From: Junio C Hamano <gitster@pobox.com>
To: git@vger.kernel.org
Cc: Alexey Pelykh <alexey.pelykh@gmail.com>
Subject: Re: Non-blob .gitmodules and .gitattributes
Date: Fri, 14 Jun 2024 08:35:56 -0700 [thread overview]
Message-ID: <xmqqbk43ilk3.fsf@gitster.g> (raw)
In-Reply-To: <4F3AD9A8-DA3E-43E2-BF9A-9D7458EED7EA@gmail.com> (Alexey Pelykh's message of "Fri, 14 Jun 2024 14:03:05 +0200")
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.
next prev parent reply other threads:[~2024-06-14 15:35 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-14 12:03 Non-blob .gitmodules and .gitattributes Alexey Pelykh
2024-06-14 15:35 ` Junio C Hamano [this message]
2024-06-14 15:43 ` Alexey Pelykh
2024-06-18 18:31 ` Jeff King
2024-06-18 19:07 ` Alexey Pelykh
2024-06-18 20:14 ` Junio C Hamano
2024-06-18 23:33 ` Jeff King
2024-06-18 23:44 ` [PATCH 0/4] .git{ignore,attributes} directories? Junio C Hamano
2024-06-18 23:44 ` [PATCH 1/4] .gitignore: introduce GITIGNORE_FILE CPP macro Junio C Hamano
2024-06-18 23:44 ` [PATCH 2/4] attr: notice and report read failure of .gitattributes files Junio C Hamano
2024-06-19 0:21 ` Eric Sunshine
2024-06-19 1:18 ` Junio C Hamano
2024-06-19 2:35 ` Eric Sunshine
2024-06-19 13:57 ` Jeff King
2024-06-20 16:20 ` Junio C Hamano
2024-06-18 23:44 ` [PATCH 3/4] exclude: notice and report read failure of .gitignore files Junio C Hamano
2024-06-18 23:44 ` [PATCH 4/4] submodule: ignore .gitmodules that is not a regular file Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqbk43ilk3.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=alexey.pelykh@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.