Re: [PATCH 0/3] Updates to the safe.directory config option
- From
Derrick Stolee <derrickstolee@github.com>
- Date
- Apr 13, 2022, 16:25 UTC
- Message-ID
- <e8383303-e82c-dc23-9f28-6ff566021e82@github.com>
- In-Reply-To
- <xmqq35iharig.fsf@gitster.g>
On 4/13/2022 12:15 PM, Junio C Hamano wrote:
Show 9 quoted lines
> "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes: > >> Here is a very fast response to the security release yesterday. > > Wow. While I were down the whole day yesterday after sending the > release announcement, it seems a lot have happened X-<. Does your > "a very fast" expect only "wow, thanks for a fast reponse", or does > it also expect "ok, we'll take a deep look with a spoonful of salt > as it was prepared in haste"?
I tried to do my due diligence here, but I will admit to some amount of haste being applied due to the many distinct sources that have motivated the change.
Show 20 quoted lines
>> The second patch here is an adaptation from a contributor who created a pull >> request against git/git [1]. I augmented the patch with a test (the test >> infrastructure is added in patch 1). >> >> The third patch is a change to the safe.directory config option to include a >> possible "*" value to completely opt-out of the check. This will be >> particularly helpful for cases where users run Git commands within a >> container. This container workflow always runs as a different user than the >> host, but also the container does not have access to the host's system or >> global config files. It's also helpful for users who don't want to set the >> config for a large number of shared repositories [2]. > > Let me take a look how well these integrate into the maintenance > tracks. > > I would appreciate something that is targetted and narrow that can > be applied to the oldest maintenance track (2.30.3) and then merged > upwards, plus niceties on top that does not necessarily have to > apply to the oldest ones if the surrounding code or tests were > changed more recently.
The tests that are added are in a new test file, so hopefully those don't collide with anything.
The changes in setup.c apply within the ensure_valid_ownership() so should apply to any versions that have the fix.
Thanks, -Stolee