Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use fuzzing for testing #15

Closed
djc opened this issue May 22, 2018 · 8 comments
Closed

Use fuzzing for testing #15

djc opened this issue May 22, 2018 · 8 comments
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@djc
Copy link
Member

djc commented May 22, 2018

Initially, can use this to test decoding routines. There's an example at https://github.com/djc/tokio-imap/tree/master/imap-proto/fuzz that might be useful in getting this off the ground.

@spacejam
Copy link

Happy to lend a hand on this. Which specific decoding methods are high priority for this?

@djc
Copy link
Member Author

djc commented Nov 20, 2018

Great, your help is much appreciated! Packet decoding by way of Endpoint::handle() would be a good starting point.

@Ralith Ralith added enhancement New feature or request good first issue Good for newcomers labels Mar 13, 2020
@Ralith
Copy link
Collaborator

Ralith commented Mar 13, 2020

Naively we could just throw fuzzer data as UDP packets at the implementation, but that wouldn't get us very far because the fuzzer is spectacularly unlikely to make any progress through the cryptographic handshake, leaving the bulk of the implementation untested. A good solution for end-to-end testing might be to add a hook to inject arbitrary data into the plaintext of an arbitrary packet between arbitrary frames, then use that in a fuzzing target to perturb an otherwise valid scripted session like the lifecycle unit test.

@Ralith
Copy link
Collaborator

Ralith commented May 20, 2020

Now that we've gracefully encapsulated the stream logic into the Streams type, it would make an excellent candidate for targeted fuzzing without any elaborate measures needed. As illustrated in #774, there's definitely enough complexity there to merit it.

@jafow jafow mentioned this issue Jul 26, 2020
@stammw
Copy link
Contributor

stammw commented Sep 13, 2020

A fuzzing effort has been made for VarInt on h3. Would you be interested to import it ?

@Ralith
Copy link
Collaborator

Ralith commented Sep 24, 2020

Certainly! I'm going to go ahead and close this since we've got some fuzzing going now; we should open new issues for specific interfaces of interest.

@Ralith Ralith closed this as completed Sep 24, 2020
@hmuint32
Copy link

hmuint32 commented Feb 23, 2024

@djc, i am having compilation issue with: cargo fuzz check in one of my local dev with stable rust.


92 |     use arbitrary::{Arbitrary, Result, Unstructured};
   |         ^^^^^^^^^ use of undeclared crate or module `arbitrary`

error[E0432]: unresolved import `arbitrary`
  --> /localpath/.cargo/registry/src/index.crates.io-6f17d22bba15001f/quinn-proto-0.10.6/src/lib.rs:92:9
   |
92 |     use arbitrary::{Arbitrary, Result, Unstructured};
   |         ^^^^^^^^^ use of undeclared crate or module `arbitrary`

    Checking zbus v3.10.0
For more information about this error, try `rustc --explain E0432`.
error: could not compile `quinn-proto` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...
Error: failed to build fuzz script: ASAN_OPTIONS="detect_odr_violation=0" RUSTFLAGS="-Cpasses=sancov-module -Cllvm-args=-sanitizer-coverage-level=4 -Cllvm-args=-sanitizer-coverage-inline-8bit-counters -Cllvm-args=-sanitizer-coverage-pc-table -Cllvm-args=-sanitizer-coverage-trace-compares --cfg fuzzing -Clink-dead-code -Zsanitizer=address -Cllvm-args=-sanitizer-coverage-stack-depth -Cdebug-assertions -C codegen-units=1" "cargo" "check" "--manifest-path"

For Posterity, i am including quinn-proto as part of my fuzz target's Cargo.toml as
quinn-proto = { version = "0.10.6", features = ["arbitrary"] } , to get my build to be successful. I guess it'd be nice to have that documented somewhere, not an issue..

@djc
Copy link
Member Author

djc commented Feb 27, 2024

Happy to review a PR with documentation improvements!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

5 participants