c_src: do not tinker with user's ~/.gitconfig #279
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In commit 7bb33e4 (take git action as suggested on an "unsafe directory"), git was told that the directory with the source tree was safe to use.
What safe.directory means, is that directories that are owned by another user are safe to use. This is meant to be used by teams that share a common git tree. In such a situation, git by default refuses to use that directory, and also refuses to run any hook from that directory; see "man git-config" for the details and rationale.
In the case of github workflows, the user that runs the git checkout is not the same as the one that actually runs the job (supposedly the checkout is done outside the container, while the job is done inside).
However, commit 7bb33e4 got it slightly wrong on three counts:
the directory added to the safe list is hard-coded, which means it is most probably unfit for the local setup; furthermore, it is not robust in the face of Github changing the location where it exposes the git tree in workflow jobs;
tweaking the git configuration is done from the Makefile, which means it changes the git config of the user running the build; it is very bad practice to do so, and may conflict with the security policy for that user;
the modification is done unconditionally, which leads to an arbitrary number of entries added to the safe list: each time the build is attemped, the directory is added to the safe list, causing an ever-growing list of exactly the same value.
The correct solution is two fold:
when building locally, users will (most probably) have cloned the repository, so they own the local clone, and thus do not need the safe entry; if they are using a shared repository, they already know what to do;
in the Github workflow, add a step to effectively disable the safety check for the directory where the checkout was done, rather than hard-coding an arbitrary location.