[20486] in Kerberos_V5_Development
Re: oss-fuzz Ideal integration
daemon@ATHENA.MIT.EDU (Greg Hudson)
Tue Apr 30 11:12:00 2024
Message-ID: <461c8f5a-f9b1-49e2-a875-881358c8785f@mit.edu>
Date: Tue, 30 Apr 2024 11:11:41 -0400
MIME-Version: 1.0
To: Arjun <pkillarjun@protonmail.com>, "krbdev@mit.edu" <krbdev@mit.edu>
Content-Language: en-US
From: "Greg Hudson" <ghudson@mit.edu>
In-Reply-To: <lp7xa9tfvNUuqThhJEPskvUBD3i1p8XFx6QiRliMvk6BTdPTdBX1ANBBbhCVkGlh_ygG3lz91tgP_lUlVrdjTmVNGCMBS91BJODZmXpNSWY=@protonmail.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
[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.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
