OSS-Fuzz integration for Zebra — reviewed by OSS-Fuzz, waiting on ZF maintainer buy-in

[robustfengbin]

Hi Zebra maintainers,

I've built and have been running a coverage-guided fuzzing suite for Zebra, and I'd like to hand it to the Foundation. There's an OSS-Fuzz integration PR open for it, and OSS-Fuzz has now reviewed that PR — the one thing they're waiting on is you.

DavidKorczynski (OSS-Fuzz) on google/oss-fuzz#15900:

The project itself looks good, but we need maintainer buy in as well. Could you coordinate this with maintainers? It would be good to also have the fuzzing harness in the upstream repository, so maintenance is clear and also to validate that fuzzing has benefit to the project.

So this is me coordinating, as asked.

What already exists

• 15 libFuzzer targets over consensus-critical, untrusted-input surfaces. That includes the surfaces that went live with NU6.3 "Ironwood" on mainnet at height 3,428,143 (2026-07-28) — v6 transaction parsing and semantics, and the Ironwood shielded-pool value-balance codec — alongside block/transaction deserialization, the P2P wire protocol, transparent and shielded address parsing, the note commitment tree, Equihash, the script interpreter (run differentially against zcash_script), and the JSON-RPC surface.
• Harnesses and seed corpora: https://github.com/robustfengbin/zebra-fuzz-m3
• Running under ClusterFuzzLite on GitHub Actions — stable, no crashes and no false-positive noise so far, so the harnesses are ready to run unattended and won't spam anyone's issue tracker.
• CLA signed; harnesses build and run clean. The OSS-Fuzz-side trial build hasn't been triggered yet — for a new project that needs an OSS-Fuzz maintainer to kick off.

On "validate that fuzzing has benefit"

The most direct evidence I can offer is that this bug class is not hypothetical for Zebra. I previously reported CVE-2026-34202 (GHSA-qp6f-w4r3-h8wg) — a V5 transaction hash panic reachable over P2P — through the Foundation's disclosure process. Transaction deserialization and the P2P wire protocol are exactly the surfaces this harness family covers, and continuous fuzzing is what keeps that class of regression from coming back after a fix.

For scale: as of oss-fuzz master c73e4ccf (2026-07-29) I enumerated all 1,369 entries under projects/ and checked them against the Zcash-ecosystem crates and clients I know of — zebra, zcashd, librustzcash, halo2, orchard, sapling, pasta_curves, zip32, reddsa, incrementalmerkletree, lightwalletd among them. None is there. bitcoin-core, monero, go-ethereum, tendermint, cosmos-sdk and aptos-core all are.

What the integration gives ZF, at no cost to the Foundation: continuous 24/7 fuzzing on Google's infrastructure, automatic regression tracking so a fixed bug stays fixed, coverage reports over the surfaces above, and a managed disclosure pipeline with a 90-day embargo for anything it finds.

What I'm asking for

OSS-Fuzz's acceptance criteria require primary_contact to be an established committer of the project, verified against the repository's version-control history. I'm not a Zebra committer, so that field has to be one of you. Concretely:

1. Upstreaming the harnesses — which OSS-Fuzz also suggested. If you're open to it, I'll open a PR moving the harnesses into ZcashFoundation/zebra under fuzz/, following your contribution process. That makes maintenance ownership explicit, which is what they asked for. I'd keep maintaining them and stay on auto_ccs.
2. A maintainer comment on the OSS-Fuzz PR saying the Foundation supports the integration, plus a committer email for primary_contact. To be clear about the burden: that email is a field OSS-Fuzz's rules require, plus a CC — no on-call, no response SLA, nothing routed to you by default. I triage everything OSS-Fuzz reports and maintain the harnesses; you'd only hear from me when something is real and needs a Zebra-side fix.

Either way the harnesses are yours to take, relicense, rewrite, or extend. And if the Foundation would rather not have this — that's a completely fine answer; I'll say so on the PR and close it.

Happy to walk anyone through the targets, the differential script harness, or the ClusterFuzzLite setup.

Thanks,
Robust (@robustfengbin)

[natalieesk]

Thank you for this, we will discuss as a team and let you know shortly.

[alchemydc]

Looking at this now. Congrats @robustfengbin on getting GOOG to accept the project. That was the one risk I saw in your grant application and am pleased to see you cleared that hurdle. I think the big question is do we want to point the OSS Fuzz at Zebra itself (which would require us to upstream a few things), or at your snapshot, which is presently a release or two behind. Also the obvious question of control and admin responsibility / overhead of the integration going forward. What are your thoughts?

[robustfengbin]

Thanks both.

On Google's side the code review is effectively behind us — David's words were that the project itself looks good. What's open is the maintainer piece: his review is formally "changes requested", and the trial build needs someone on their side to kick off. So the remaining step is maintainer confirmation rather than a technical review issue.

I agree that pointing OSS-Fuzz at upstream Zebra is the better long-term approach; the snapshot was only ever a way to validate the harnesses end to end. Happy to upstream the fuzz directory and its configuration, so maintenance stays with the project.

On what that takes, since you mentioned it: a self-contained fuzz/ directory — it's its own workspace, so your builds and CI time are untouched — plus about 14 lines in two crates, behind a feature that is off by default. The only change is that two internal modules become visible to the fuzz build. The corpora stay on the OSS-Fuzz side, not in your repo.

On control: I'm not asking to own this. A full handover — harnesses, seed pipeline, corpora, ClusterFuzzLite config, the OSS-Fuzz integration itself, and maintenance from there. Your repo, your primary_contact, your triage. I'll stay available for as long as that's useful.

One thing to move it forward: a committer email for primary_contact — OSS-Fuzz wants a maintainer verifiable from the project's own version-control history, which is why I came here rather than naming myself. With that I'll open the Zebra PR as a draft, so you can read the diff first.

[mpguerra]

Hi,

Thank you for your work on this!

We'd be happy to point this at upstream Zebra, we just need to prioritise this work for review :) Please submit the PR so we can take a look.

For the email address, where do we need to provide this? Should we reply directly on google/oss-fuzz#15900 ?

Happy for my email/github handle to be used.

[alchemydc]

Thanks both.

On Google's side the code review is effectively behind us — David's words were that the project itself looks good. What's open is the maintainer piece: his review is formally "changes requested", and the trial build needs someone on their side to kick off. So the remaining step is maintainer confirmation rather than a technical review issue.

I agree that pointing OSS-Fuzz at upstream Zebra is the better long-term approach; the snapshot was only ever a way to validate the harnesses end to end. Happy to upstream the fuzz directory and its configuration, so maintenance stays with the project.

On what that takes, since you mentioned it: a self-contained fuzz/ directory — it's its own workspace, so your builds and CI time are untouched — plus about 14 lines in two crates, behind a feature that is off by default. The only change is that two internal modules become visible to the fuzz build. The corpora stay on the OSS-Fuzz side, not in your repo.

On control: I'm not asking to own this. A full handover — harnesses, seed pipeline, corpora, ClusterFuzzLite config, the OSS-Fuzz integration itself, and maintenance from there. Your repo, your primary_contact, your triage. I'll stay available for as long as that's useful.

One thing to move it forward: a committer email for primary_contact — OSS-Fuzz wants a maintainer verifiable from the project's own version-control history, which is why I came here rather than naming myself. With that I'll open the Zebra PR as a draft, so you can read the diff first.

Appreciate the perspective @robustfengbin . Please go ahead and open a PR to upstream the changes into Zebra and we will expedite review + merge and then close the loop properly with the OSS-Fuzz team. Thanks!

[robustfengbin]

@mpguerra @alchemydc

Thanks — the PR is open: #11221.

On the email address: yes, replying on google/oss-fuzz#15900 works. OSS-Fuzz
wants a primary_contact that is verifiable from the project's own commit
history, so it is best coming from you directly.

[alchemydc]

@mpguerra @alchemydc

Thanks — the PR is open: #11221.

On the email address: yes, replying on google/oss-fuzz#15900 works. OSS-Fuzz wants a primary_contact that is verifiable from the project's own commit history, so it is best coming from you directly.

Thanks. I see it and appreciate the hard work and the contribution.