ci: OSS-Fuzz build integration, run on CI via ClusterFuzzLite

[FMSMITH91]

Adds the OSS-Fuzz build contract for the five Atheris harnesses already in tests/fuzz/, and runs it on pull requests.

First, the honest bit about the upstream program

OSS-Fuzz's stated acceptance bar is that a project "must have a significant user base and/or be critical to the global IT infrastructure". A self-hosted game control panel will not clear that, so submitting to https://github.com/google/oss-fuzz would almost certainly be declined.

ClusterFuzzLite is the answer to exactly that problem — same base images, same build contract, same crash reporting and dedup, running on this repo's own CI with no enrolment. That's what this PR wires up.

And if the project ever does qualify, these three files are the submission: drop them into projects/linuxgsm-panel/ with a Dockerfile that clones instead of copies, plus a contact email.

What's here

.clusterfuzzlite/Dockerfile      base-builder-python + the pinned requirements
.clusterfuzzlite/build.sh        compiles every fuzz_*.py, zips its seed corpus
.clusterfuzzlite/project.yaml    language, engine, sanitizers
.github/workflows/cflite_pr.yml  code-change fuzzing on PRs -> SARIF

Two things the OSS-Fuzz Python guide doesn't cover for a repo shaped like this

• The panel is an application, not a pip package. There's no setup.py, so the guide's pip3 install . doesn't apply. The repo root goes on PYTHONPATH instead — that's both how the harnesses' import ssh_manager resolves and how PyInstaller finds those modules to bundle.
• The harnesses pre-load paramiko / eventlet.tpool / config via importlib.import_module("..."), deliberately, so instrument_imports() only instruments the parser under test. A string is invisible to PyInstaller's static analysis, so those are declared as --hidden-import. Without them the targets build clean and die on their first import — which is why bad-build-check is left on: that's precisely the failure mode here.

Also worth flagging: run_fuzzers defaults to language: c++ and does not inherit the build step's setting, so it's set explicitly.

Deliberate overlap with fuzz.yml

fuzz.yml is the broad sweep — every target, fixed 60s, plain Atheris. This runs in code-change mode: only what the diff touched, with real crash dedup, filing findings as SARIF in the Security tab next to the CodeQL and Bandit alerts. Dropping either is reasonable; keeping both is what this does. Say the word if you'd rather I retire fuzz.yml.

Not enabled

Batch fuzzing, corpus pruning and coverage all need a separate storage repo plus a PAT to keep a corpus between runs. Without one they'd start from the committed seeds every time and learn nothing. .clusterfuzzlite/README.md documents how to turn them on.

Verification

Done: shellcheck clean, both YAML files parse, every corpus directory resolves to a target, repo lint clean.

Not done: the Docker build itself — there's no Docker on this machine, so I could not run helper.py build_fuzzers / check_build. The README lists those commands, and this PR's own CI run is the first real execution. If the build is wrong, this PR is where it shows.

🤖 Generated with Claude Code

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.