Skip to content

Coordinate OSS-Fuzz target for Android immutable collection construction #8669

New issue
New issue
Open
Open
Coordinate OSS-Fuzz target for Android immutable collection construction#8669
Labels
P2type=defectBug, not working as expected

Description

@thinhnallf
thinhnallf
opened on Sep 10, 2026

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.

Activity

  1. thinhnallf
    added
    type=defectBug, not working as expected
    on Sep 10, 2026

  2. cpovirk commented on Sep 10, 2026

    @cpovirk
    cpovirk
    on Sep 10, 2026
    Member

    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 :)

  3. thinhnallf commented on Sep 10, 2026

    @thinhnallf
    thinhnallf
    on Sep 10, 2026
    Author

    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.

  4. cpovirk commented on Sep 11, 2026

    @cpovirk
    cpovirk
    on Sep 11, 2026
    Member

    Option A SGTM as the easy way forward. Thanks.

  5. thinhnallf commented on Sep 12, 2026

    @thinhnallf
    thinhnallf
    on Sep 12, 2026
    Author

    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.

  6. DavidKorczynski commented on Sep 12, 2026

    @DavidKorczynski
    DavidKorczynski
    on Sep 12, 2026

    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.

  7. thinhnallf commented on Sep 12, 2026

    @thinhnallf
    thinhnallf
    on Sep 12, 2026
    Author

    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.

  8. cpovirk commented on Sep 12, 2026

    @cpovirk
    cpovirk
    on Sep 12, 2026
    Member

    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.

  9. thinhnallf commented on Sep 12, 2026

    @thinhnallf
    thinhnallf
    on Sep 12, 2026
    Author

    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.

  10. cgdecker
    added
    P2
    on Sep 15, 2026

  11. ius-sharma commented on Sep 20, 2026

    @ius-sharma
    ius-sharma
    on Sep 20, 2026

    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?

  12. im-alok74 commented on Sep 27, 2026

    @im-alok74
    im-alok74
    on Sep 27, 2026

    Hi, I'd like to work on this issue if it's still available. Could I be assigned? Happy to share a quick plan first if that's useful.

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2type=defectBug, not working as expected

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions