remove libfuzzer-best recommendation (#2466)

0.13.1 (#2343)

Adding StdXObserver Docs (#2311)

* Adding StdXObserver Docs

* fixing docs

* code cleanup

* moving example

* improving exclusion rules

* adding impls for features

* adding test exclusions

* excluding miri from OS including tests

* fixing CI

---------

Co-authored-by: Dongjia "toka" Zhang <[email protected]>

LibAFL 0.12 (#1823)

Another attemp to fix CI (#1744)

* fixing?

* more

* delete macos build_and_run fuzzers as its runtime exceeds 360minutes and can't fix it

Bump to 0.11.1 (#1491)

Bump to 0.11.0 (#1469)

Co-authored-by: Dominik Maier <[email protected]>

Use listings for `baby_fuzzer` book chapter (#1289)

* Clarify setup steps for the baby fuzzer

Specifically:
- Explicitly mention that the dependency path must point to a specific
  directory in the cloned repo (and not the root directory)
- Explicitly mention how to manually trigger the panic in the harness
  for testing purposes

* Clean up documentation on the baby fuzzer

Since the baby fuzzer chapter of the documentation is done in a
"tutorial", step-by-step fashion, it would be nice to be able to see
where exactly new lines have to be placed in the existing code. To that
end, the code used in the tutorial is moved to snippets (as is done in
the Rust Book), as it allows for much more convenient maintenance of the
snippets, as well as easy hiding of the non-important code on any given
snippet.

Furthermore, a few minor fixes are applied; a typo on a comment and a
missing unsafe block.

* Fix code snippet attributes for baby fuzzer

Specifically:
- Remove unnecessary `compile_fail` attribute
- Add `ignore` attribute to the snippets of the complete baby fuzzer. As
  explained in [#1290], it is expected for the baby fuzzer to return a
  non-0 exit code, so this should not trigger a failure during `mdbook
  test`.

* Fix CLI snippet language

For CLI snippets, the "language" should be set to `console`.

* Remove nested safe block in baby_fuzzer listings

Fix `is_valid` on Windows (#1217)

* git add -u

* fix cfg

* pub

---------

Co-authored-by: Andrea Fioraldi <[email protected]>

Remove {update,clear}_hash from ObserverWithHashField, add hasher (ex…

…tending #1019) (#1028)

* libafl: Remove `{update,clear}_hash` from `ObserverWithHashField`

These methods aren't used by `NewHashFeedback`, so there's no compelling reason
to keep them in the interface. They preclude implementations of
`ObserverWithHashField` that calculcate a hash on-the-fly from a value. For
example, my use-case is to store the stdout of a process, and use
`NewHashFeedback` to only collect inputs that result in new messages on stdout.

Both of these methods are pretty suspicious to begin with - why should other
code be able to update the internal state of the observer? What are the
semantics of `update_hash`? If there are compelling reasons to keep these
methods, let's clarify their intent in the documentation.

* libafl: Return hash by value from `ObserverWithHashField`

This allows implementors of this trait to not store the hash, but rather to
compute it on-the-fly. Since `Option<u64>` is `Copy` (and quite small), and
this method is called once per execution of the target program, this is likely
to have negligible performance impact.

* libafl: Implement `ObserverWithHashField` for `ValueObserver`

This demonstrates the utility of the previous two commits. Now, `ValueObserver`
can be used with `NewHashFeedback`.

* Clippy, move to ahasher

* Oops :)

---------

Co-authored-by: Langston Barrett <[email protected]>