Hi, I'd like to contribute continuous fuzzing coverage for this project and would like your input on the best way to land it.
What I have: five libFuzzer targets written in Swift that decode arbitrary bytes through the OCI parsing code in ContainerizationOCI:
- image manifests (config and layer descriptors)
- image indexes (platform entries per manifest)
- full image config documents (rootfs, history)
- runtime spec documents (process, mounts, annotations)
- image reference strings through
Reference.parse
Each target walks the decoded values and re encodes them to exercise the full Codable path. Seed corpora of valid documents are included, and everything builds and runs on Linux with Swift 6.2 (needing the libarchive, bzip2, lzma and openssl development packages).
Why I'm asking first: I opened an integration for this project in Google's OSS Fuzz program (google/oss-fuzz#16070) and the reviewer's policy is that the fuzz target sources should live in the upstream repository, with maintainer awareness, rather than in the oss fuzz repo itself. The gRPC Swift package follows this layout with a FuzzTesting sub package, and that is the arrangement I'd propose here: the five targets as a small sibling Swift package inside this repository, with the oss fuzz build cloning this repo and building that package.
Questions:
- Would you welcome this contribution, and do you have a preferred location for it (for example a top level
FuzzTesting/ directory)?
- Any requirements on my side regarding contribution process, license headers, or CI wiring you'd want alongside it?
For context on the kind of results this testing can produce: the same approach on the taglib audio metadata library found an undefined behavior issue in its ASF parser within the first minute of fuzzing (taglib/taglib#1429, fixed in taglib/taglib#1430), which is the sort of early catch continuous fuzzing gives parsing code that handles untrusted input.
Happy to send the package as a pull request once you confirm the approach. cc @dcantah
Hi, I'd like to contribute continuous fuzzing coverage for this project and would like your input on the best way to land it.
What I have: five libFuzzer targets written in Swift that decode arbitrary bytes through the OCI parsing code in ContainerizationOCI:
Reference.parseEach target walks the decoded values and re encodes them to exercise the full Codable path. Seed corpora of valid documents are included, and everything builds and runs on Linux with Swift 6.2 (needing the libarchive, bzip2, lzma and openssl development packages).
Why I'm asking first: I opened an integration for this project in Google's OSS Fuzz program (google/oss-fuzz#16070) and the reviewer's policy is that the fuzz target sources should live in the upstream repository, with maintainer awareness, rather than in the oss fuzz repo itself. The gRPC Swift package follows this layout with a FuzzTesting sub package, and that is the arrangement I'd propose here: the five targets as a small sibling Swift package inside this repository, with the oss fuzz build cloning this repo and building that package.
Questions:
FuzzTesting/directory)?For context on the kind of results this testing can produce: the same approach on the taglib audio metadata library found an undefined behavior issue in its ASF parser within the first minute of fuzzing (taglib/taglib#1429, fixed in taglib/taglib#1430), which is the sort of early catch continuous fuzzing gives parsing code that handles untrusted input.
Happy to send the package as a pull request once you confirm the approach. cc @dcantah