You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I hit a _very_ hard to diagnose issue today after switching part of a
CI environment. It turns out that due to non-privileged container
magic the CI step was not running as the user that cloned the repo.
This manifested as the sdist generated during this step just not
having a few extra data files; but the build still passed. So several
steps later, suddenly files have just vanished from the sdist, which
of course is not something that is checked for and so testing blows up
in very strange ways.
After I understood what was going on, there is a _tiny_ little message
hidden amongst the logs that gives a hint of what's going on.
...
writing requirements to src/proj.egg-info/requires.txt
writing top-level names to src/proj.egg-info/top_level.txt
listing git files failed - pretending there aren't any
reading manifest file 'src/proj.egg-info/SOURCES.txt'
writing manifest file 'src/proj.egg-info/SOURCES.txt'
...
What is actually happening is that if you run git you get "git status
fatal: detected dubious ownership in repository at '/..proj'". This
is the well-known CVE-2022-24765 issue where trusting a `.git` config
dir from another user causes problems. In
6a3bb96 all the calls in
setuptools_scm/git.py were updated to use `--git-dir` directly -- git
will not complain if you have told it to explicitly trust the config
dir like this.
However, there are calls in _file_finders/git.py to find the top-level
that are not using this. It silently (modulo an easily missed log)
skips adding files when this occurs.
I can not see that this would ever be the behaviour you would want.
If it had of exploded telling me the git call failed, it would have
short-cut all of the problem finding.
This adds an explicit match on the static part of this git failure
message and raises a SystemExit if it hits. A test case that mocks
such a situation is added.
I have increased the "listing git files failed" to a warning; similar
to the "shallow clone" warning. It seems like this is actually quite
important. I'm sure someone relies on it for some reason, but I can't
quite see why you'd want to ignore that files are not being added to
your sdist. This necessitates ignoring this warning in several
places, which I think is an improvement, as at least we have a clearer
overview of where addition is being ignored if we want to examine this
behaviour more closely.
Closes: #784
Signed-off-by: Ian Wienand <iwienand@redhat.com>
0 commit comments