Coordinate OSS-Fuzz target for Android immutable collection construction

[thinhnallf]

Guava Version

33.7.1-android and master commit 4afb1e0

Description

Hi Guava maintainers,

I’m an external contributor, and I opened the following OSS-Fuzz pull
request to add fuzzing coverage for Android immutable-collection
construction:

OSS_FUZZ_PR_URL

The target exercises the Android variants of:

• ImmutableMap
• ImmutableSet
• ImmutableBiMap

The existing Guava OSS-Fuzz targets did not cover construction of these
Android implementations.

Local validation completed:

• clean OSS-Fuzz build;
• check_build passed;
• the target was discovered and executed by Jazzer;
• a small-input negative control completed normally;
• a mutation campaign starting from an empty corpus reached the intended
  Android collection code.

The OSS-Fuzz reviewer asked me to coordinate with the Guava maintainers
before proceeding.

Could you please confirm which integration approach you prefer?

1. Keep the fuzz target and Android build integration in the OSS-Fuzz
   repository; or
2. Maintain the fuzz target in the Guava repository and have OSS-Fuzz
   build it from upstream.

I’m happy to adjust the contribution based on your preference.

Thank you.

Example

The tested Jazzer target and OSS-Fuzz integration are available in:

https://github.com/google/oss-fuzz/pull/16117

The target exercises construction of the Android implementations of
ImmutableMap, ImmutableSet, and ImmutableBiMap. It includes a small-input
negative control and has been verified with a clean OSS-Fuzz build and
check_build.

This issue is primarily intended to coordinate ownership and placement of
the fuzz target, as requested during OSS-Fuzz review.

Expected Behavior

I would like the Guava maintainers to confirm the preferred ownership and
location of this fuzz target:

1. Keep the target in the OSS-Fuzz repository; or
2. Maintain the target in the Guava repository and have OSS-Fuzz build it
   from upstream.

I will adapt the contribution according to the maintainers' preference.

Actual Behavior

The target is currently implemented in an OSS-Fuzz pull request. During
review, I was asked to coordinate with the Guava maintainers before the
OSS-Fuzz contribution can proceed.

Packages

com.google.common.collect

Platforms

Android

Checklist

• I agree to follow the code of conduct.

• I can reproduce the bug with the latest version of Guava available.

[cpovirk]

Thanks. Can you walk me through the tradeoffs here? I guess that naively I think "There are already some Java source files related to Guava in the OSS-Fuzz project, so presumably it makes sense to add any more there, too?" But I may be missing some difference between the existing and proposed files, or we may have started off on the wrong path by having the existing files in OSS-Fuzz in the first place.

Gemini's take is that "files in OSS-Fuzz" was the original path but that OSS-Fuzz maintainers might prefer "files in Guava" nowadays? It sounds like part of the reason for that wouldn't apply(?) here: I don't think we'll be fuzzing internal APIs, so there's no need to keep the fuzzer in strict sync with the Guava code. (Now, maybe some other fuzzer someday will want to operate on internal APIs.) The other reasons would still apply: "Files in Guava" might be more likely to encourage additional fuzzers, and it would make it easier to run the fuzzers manually.

I guess I would say that I don't object to adding here if the OSS-Fuzz developers prefer, and I don't object to adding more to the OSS-Fuzz repo instead if they're fine with that. But let me know if you think I should have more of an opinion :)

[thinhnallf]

Thanks — happy to lay out the tradeoffs as I understand them.

Option A — keep it in OSS-Fuzz (projects/guava/):

• Pro: consistent with where the existing Guava targets already live; nothing for the Guava build to carry.
• Pro: no new build wiring in Guava itself.
• Con: the fuzzer isn't visible or runnable from a normal Guava checkout, so it's less discoverable and harder for contributors to run manually.

Option B — maintain it in the Guava repo, OSS-Fuzz builds it from upstream:

• Pro: easier to run manually from a Guava checkout, and more likely to encourage additional fuzzers over time.
• Pro: the target lives next to the code it exercises.
• Con: adds a small amount of build wiring on the Guava side.

One point that doesn't really apply here: keeping the fuzzer in strict sync with internal Guava APIs. This target only touches public construction APIs (ImmutableMap/ImmutableSet/ImmutableBiMap), so there's no internal-API coupling that would argue for co-locating it in Guava. (A future fuzzer that does exercise internals would be a stronger reason to keep things in the Guava repo.)

Given that, I don't have a strong preference and I'm happy to follow yours. If it helps: the current PR (google/oss-fuzz#16117) already implements Option A and passes a clean build_fuzzers + check_build, so that's the lowest-friction path if you're fine with it. If you'd prefer Option B, I'll move the target into the Guava repo and adjust the OSS-Fuzz side to build it from upstream. Just let me know which you'd like.

[cpovirk]

Option A SGTM as the easy way forward. Thanks.

[thinhnallf]

Thanks @cpovirk! I'll go with Option A — keeping AndroidImmutableCollectionsHashFloodingFuzzer in the OSS-Fuzz repo. It's already implemented and passing check_build in google/oss-fuzz#16117, using only public Guava construction APIs (ImmutableMap/ImmutableSet/ImmutableBiMap). I'll ask the OSS-Fuzz reviewers to proceed with the merge and reference your approval here.

[DavidKorczynski]

The reason for preference on Option B from OSS-Fuzz's side is that we are unable to review fuzzers for Guava. We don't know if they exercise the threat model correctly, whether findings from them will be valuable etc. We have at times integrated fuzzing harnesses in OSS-Fuzz (I think even for Guava) but it's not a super viable plan. Furthermore, following agentic development this has become harder as we're now seeing many more harnesses being submitted to OSS-Fuzz from many different projects.

Can we go with Option B for these reasons? Otherwise we're in a situation in OSS-Fuzz where (1) we don't know if the fuzzing harnesses make sense; (2) we don't know if the user submitting the harnesses originate from the upstream repo.

[thinhnallf]

Thanks both. Given @DavidKorczynski's point that OSS-Fuzz can't easily review Guava-specific harnesses or verify their provenance, let's go with Option B — I'll contribute AndroidImmutableCollectionsHashFloodingFuzzer directly into the Guava repo, and have the OSS-Fuzz build compile it from the upstream checkout. @cpovirk — since you were fine either way, where would you prefer the harness to live in the tree (e.g. a fuzzing/ dir or under guava-tests/)? It only uses public construction APIs (ImmutableMap/ImmutableSet/ImmutableBiMap), so it shouldn't couple to internals. I'll open a Guava PR and repoint oss-fuzz#16117 to build from it.

[cpovirk]

Thanks. In our repo is fine, too. I'd go with "guava-fuzzers" or "guava-fuzzing" or something along those lines: A separate module seems nice, and we seem attached to the "guava-" prefix in our existing modules.

[thinhnallf]

Thanks! I went with a standalone guava-fuzzers module as suggested. PR: #8673

Layout:

guava-fuzzers/
  pom.xml
  src/main/java/AndroidImmutableCollectionsHashFloodingFuzzer.java

One open choice: I left the module out of the root pom <modules> on purpose, so
ordinary mvn install/releases don't build it and the main build graph doesn't pick up a
Jazzer dependency (OSS-Fuzz compiles the harness directly with javac). Happy to wire it
into <modules> instead if you'd rather have it built/checked by CI — just let me know
which you prefer and I'll adjust.

[ius-sharma]

Hi @cgdecker @DavidKorczynski @cpovirk @thinhnallf @mkbehr, could you please explain how this works? I’m new and eager to learn, but I’m not sure how or where to start. Could you please help me out?