Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fuzz Tests Are Crashing at Start-up on ClusterFuzz #1905

Closed
1 task done
DaveLak opened this issue Apr 22, 2024 · 2 comments
Closed
1 task done

Fuzz Tests Are Crashing at Start-up on ClusterFuzz #1905

DaveLak opened this issue Apr 22, 2024 · 2 comments

Comments

@DaveLak
Copy link
Contributor

DaveLak commented Apr 22, 2024

PR #1901 was successful in fixing the broken build but resurfaced another issue that is preventing the fuzzer from running.

The Problem

It appears that a Git executable is not available in the ClusterFuzz container environment where fuzz tests are executed, causing an error in the fuzz harnesses when GitPython attempts to initialize.

This issue has been previously seen and reported on the OSS-Fuzz issue tracker: google/oss-fuzz#10600

Relevant Portion of the ClusterFuzz Crash Logs from 2024-04-20
# <Prior output omitted for brevity>
INFO: Instrumenting git.index.util
INFO: Instrumenting git.remote
INFO: Instrumenting [git.repo.fun](http://git.repo.fun/)
Traceback (most recent call last):
  File "git/__init__.py", line 296, in <module>
  File "git/__init__.py", line 287, in refresh
  File "git/cmd.py", line 631, in refresh
ImportError: Bad git executable.
The git executable must be specified in one of the following ways:
    - be included in your $PATH
    - be set via $GIT_PYTHON_GIT_EXECUTABLE
    - explicitly set via git.refresh(<full-path-to-git-executable>)

All git commands will error until this is rectified.

This initial message can be silenced or aggravated in the future by setting the
$GIT_PYTHON_REFRESH environment variable. Use one of the following values:
    - quiet|q|silence|s|silent|none|n|0: for no message or exception
    - warn|w|warning|log|l|1: for a warning message (logging level CRITICAL, displayed by default)
    - error|e|exception|raise|r|2: for a raised exception

Example:
    export GIT_PYTHON_REFRESH=quiet


The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "[fuzz_config.py](http://fuzz_config.py/)", line 26, in <module>
  File "PyInstaller/loader/pyimod02_importers.py", line 419, in exec_module
  File "git/__init__.py", line 298, in <module>
ImportError: Failed to initialize: Bad git executable.
The git executable must be specified in one of the following ways:
    - be included in your $PATH
    - be set via $GIT_PYTHON_GIT_EXECUTABLE
    - explicitly set via git.refresh(<full-path-to-git-executable>)

All git commands will error until this is rectified.

This initial message can be silenced or aggravated in the future by setting the
$GIT_PYTHON_REFRESH environment variable. Use one of the following values:
    - quiet|q|silence|s|silent|none|n|0: for no message or exception
    - warn|w|warning|log|l|1: for a warning message (logging level CRITICAL, displayed by default)
    - error|e|exception|raise|r|2: for a raised exception

Example:
    export GIT_PYTHON_REFRESH=quiet

[80625] Failed to execute script 'fuzz_config' due to unhandled exception!
cf::fuzzing_strategies: fork:2,value_profile:1

Possible Solution

OSS-Fuzz uses Pyinstaller to bundle fuzz harnesses and their dependencies in the compile_python_fuzzers function called by build.sh. Arguments passed to compile_python_fuzzers after the fuzz harness are forwarded to Pyinstaller, which accepts an --add-binary flag to add arbitrary binaries to the bundle and are made available to the bundled program at runtime.

We should be able to:

  1. Download a pre built Git binary from kernal.org in the container-environment-bootstrap.sh script. Never mind, the downloadable archives are source, not builds.
  2. Bundle the git available in the OSS-Fuzz build container with the fuzz harness in build.sh
  3. And use GitPython's git.refresh(<full-path-to-git-executable>) method inside a Pyintaller runtime check to initialize GitPython with the bundled Git executable when running from the bundled application.

Next Steps

DaveLak added a commit to DaveLak/GitPython that referenced this issue Apr 22, 2024
A Git executable is not globally available in the ClusterFuzz container
environment where OSS-Fuzz executes fuzz tests, causing an error in the fuzz
harnesses when GitPython attempts to initialize, crashing the tests before they
can run.

To avoid this issue, we bundle the `git` binary that is available in the OSS-Fuzz
build container with the fuzz harness via Pyinstaller's `--add-binary` flag in
`build.sh` and use GitPython's `git.refresh(<full-path-to-git-executable>)`
method inside a Pyinstaller runtime check to initialize GitPython with the
bundled Git executable when running from the bundled application.

In all other execution environments, we assume a `git` executable is available
globally.

Fixes:
- gitpython-developers#1905
- google/oss-fuzz#10600
@Byron
Copy link
Member

Byron commented Apr 23, 2024

Thanks for reporting!

This should be fixed by #1906 .

@Byron Byron closed this as completed Apr 23, 2024
DaveLak added a commit to DaveLak/GitPython that referenced this issue Apr 26, 2024
This is a second attempt at gitpython-developers#1906 and should resolve:
- gitpython-developers#1905
- google/oss-fuzz#10600

PR gitpython-developers#1906 had the right idea but wrong implementation, and the differences between
the ClusterFuzz image that it was supposed to fix and the OSS-Fuzz image where
the fix 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.

 gitpython-developers#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.
@DaveLak
Copy link
Contributor Author

DaveLak commented Apr 26, 2024

#1906 didn't quite do the trick but #1909 should 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants