`fatal: unsafe repository ('...' is owned by someone else)` and impact of CVE-2022-24765 fix for `git`

[KOLANICH]

Hi. Today I have noticed that editable installation of packages from root stopped working. It is because of git version with fix for CVE-2022-24765 has been released and delivered.

It writes that LookupError: setuptools-scm was unable to detect version for ....

Investigation and adding dumping resulted in pinpointing the error to .git.from_potential_worktree, where git errors with

fatal: unsafe repository ('...' is owned by someone else)

To add an exception for this directory, call:
	git config --global --add safe.directory

.

1. I know that editable installs from root are insecure and that just adding files to such dirs allows privelege escallation.
2. I know that pip must not execute wheel building elevated even if called from root, it should drop its rights for the time it builds wheel, and it is a flaw in pip it doesn't do that.

But those are not flaws in setuptools_scm. Let's concentrate on the flaws on setuptools_scm related to the issue.

• Use python bindings/reimpls to git when it is possible instead of console tools #705
• When any CLI operations for git are failed, setuptools_scm suppresses their output making it hard to debug what's happening #706

[KOLANICH]

The workaround to this issue is to use sudo fakeroot instead of sudo. fakeroot makes git think that the repo is owned by root, and so the security check is satisfied.

[pitrou]

I suspect many people are affected by this. It happens for example when running a Docker container where the source tree is mounted from the host.

[pitrou]

@henryiii @RonnyPfannschmidt What would be your take on this?

[RonnyPfannschmidt]

@pitrou thanks for the linked issue,

I believe it may be good/necessary to pass that config option to git

I'll make it a Fokus roughly mid next week after completing git archive support

[KOLANICH]

I believe it may be good/necessary to pass that config option to git

The doc says that config option takes no effect when passed through command line. Modifying configs is IMHO inacceptable. IMHO the solution with fakeroot and/or using bindings to more flexible git libs is more optimal.

[pitrou]

@KOLANICH Can you point to the doc that says that?

[pitrou]

Ok, found it: https://git-scm.com/docs/git-config/2.36.0#Documentation/git-config.txt-safedirectory

[pelson]

Saw the same issue. An unsafe fix is git config --global --add safe.directory '*'. This is perfectly fine in my case, as it is for CI purposes.

Setting SETUPTOOLS_SCM_DEBUG=1 was essential for diagnosing this issue - perhaps the best place to start would be to try to catch this message and make it easier to know about the issue in setuptools-scm.

In general, I agree that this is likely to come up more frequently for container use-cases once the newer git CLI is more prevalent.

[chrisburr]

Looking at the implementation in setuptools_scm.git it should be fairly straight forward to workaround this issue using --git-dir=... or by setting $GIT_DIR.

I'll try to make a pull request this afternoon.