Re: Odd git-config behavior

From: Thomas Guyot <tguyot@gmail.com>
Date: Nov 9, 2022, 07:02 UTC
Message-ID: <536bcbc6-df12-e3b8-f995-35adfd311a84@gmail.com>
In-Reply-To: <Y2rhfTYDEGQ7EhaS@sigkill.com>

On 2022-11-08 18:08, J. Paul Reed wrote:

> This does beg the question: does running "git fsck" on an untrusted
> repository as another user present a [security] problem?
>
> If so, should it?

Probably not, but I can't say for sure. Even some seemingly safe commands can be dangerous in this context; for example "git gc --auto" invokes a hook which could execute arbitrary code if run on an untrusted repo.

I haven't read the CVE but did notice the change - the primary issue if I'm not mistaken is when git behaves differently when there is a .git dir that could have been placed by a malicious user. I believe a safe approach has been taken where we have to explicitly whitelist repos or paths where the repos are trusted

Show 9 quoted lines

>> What was the return code for the git config command? If it was zero when
>> it didn't parse/output the config option you asked for that is
>> definitively a bug. If you failed to check the return code of git-config
>> then you should fix your script/tool instead.
> underworld # ~preed/src/git/git --version
> git version 2.30.2.4.g8959555cee
> underworld # GIT_PAGER=cat ~preed/src/git/git-config -l
> underworld # echo $?
> 0

We should test with the latest version... If git ignores the config it should warn (like other commands do) and not return 0.

Since git normally uses the global config when not a repo, it appears it keeps looking for the global config after it decides the local one is no good. What you see with this command is your global config not your repo's config.

Regards,

-- Thomas