oss-fuzz Ideal integration

[Greg Hudson]

[Dropping krbcore-security as this isn't a report of a security issue, 
and because I'd prefer if people don't cross-post to multiple krb5 lists.]

On 4/28/24 10:28, Arjun wrote:
> This is my initial design.
>      * You can try applying my current patch `krb.patch`, in the root 
> directory. This will show you the only changes that will be needed for 
> the build system.
>      * Fuzz targets that currently exist in 
> `oss-fuzz/projects/krb5/fuzzing` will be moved to 
> `krb5/src/tests/fuzzing`. Also I'm adding some new targets.

This looks simple enough.  I assume there would also be some translation 
of oss-fuzz/projects/krb5/fuzzing/Makefile to a krb5 Makefile.in.

>      * Adding `CIFuzz` workflow for GitHub for PR testing.

This might be a bit of a balancing act.  Currently, the krb5 CI runs 4-6 
jobs and takes about ten minutes.  I wouldn't want to dramatically 
extend the runtime, partly out of a concern for Github's resource 
consumption, but mostly because I don't want to wait a long time to get 
the all-clear before finally merging a PR.

On the flip side, it's better to learn about a problem before merging a 
PR than afterwards (a weakness of the current integration).  And I do 
generally let a PR sit for several days so I can review it with a clear 
head before merging.  Unfortunately I don't think there's an easy way 
for me to manually trigger a longer CI job without it firing on every PR 
branch push.

I see that Curl's fuzzing CI job runs in ten minutes, so maybe it's 
possible to do a decent amount of fuzzing in the same timeframe as the 
current jobs.

> krb5 implements its own crypto functions. To properly test those crypto 
> function implementations, I need to do differential fuzzing where krb5 
> crypto functions will be tested against OpenSSL and other crypto libraries.

The good news is that we don't touch lib/crypto/builtin very often, so 
most of the above CI concerns aren't an issue.

> Zero hack:
>      * Load the `Makefile.am` with hacks, so it can compile without 
> proper dependency checks for differential fuzzing;
>      Note: I like this one;

I don't understand this.

> Second hack:
>      * Not adding the fuzzing src and build into the krb5 build system, 
> but treating it as a different test;

I'm not sure I see the advantage.  In Curl, it looks like the 
curl-fuzzer job still fires off for every PR branch push, so it doesn't 
seem much different from having those materials within the main curl tree.