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
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
