Attempt 2 - Fix Missing Git Executable Causing ClusterFuzz Crash by DaveLak · Pull Request #1909 · gitpython-developers/GitPython (original) (raw)

This is a second attempt at #1906 and should resolve:

PR #1906 had the right idea but wrong implementation. The differences between the ClusterFuzz image that it was supposed to fix and the OSS-Fuzz image where it was tested led to the issue not being fully resolved.

The root cause of the issue is the same: A Git executable is not globally available in the ClusterFuzz container environment where OSS-Fuzz executes fuzz tests.

#1906 attempted to fix the issue by bundling the Git binary and using
GitPython's git.refresh(<full-path-to-git-executable>) method to set it inside the TestOneInput function of the test harness.

However, GitPython attempts to set the binary at import time via its __init__ hook, and crashes the test if no executable is found during the import.

This issue is fixed here by setting the environment variable that GitPython looks in before importing it, so it's available for the import. This was tested by setting the $PATH to an empty string inside the test files, which reproduced the crash, then adding the changes introduced here with $PATH still empty, which avoided the crash indicating that the bundled Git executable is working as expected.


Note: I didn't test this in a full ClusterFuzz environment, so it's worth noting that while it may be possible for this to continue failing because of the difference between environments that the Git executable was produced in vs. where it's run: I don't believe that will be an issue in practice because the guidance for projects (including Git itself) in OSS-Fuzz is to compile in build.sh with the libraries necessary to create the final binary that is executed in ClusterFuzz. The changes here assume that the apt repo version of Git has everything statically built. If, for some reason, it turns out that a static binary isn't what is installed, the alternative will be to build git from source or mock it. But based on my local testing thus far, I think (and hope) that won't be necessary, and this changeset should be sufficient.