-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
fuzz: introduce continuous fuzzing for Caddy #2723
Conversation
229005c
to
3f66cb5
Compare
56f2492
to
71eea0c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking pretty good. What's the status of the draft at this point?
fuzz/go.mod
Outdated
@@ -0,0 +1,10 @@ | |||
module local.tld/fuzz |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the fuzzer need to be its own module? AFAIK, having multiple modules in a repository can cause complications in some cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately, yes due to go-fuzz not yet being able to handle modules. Creating another module is a workaround as described by mvdan here. It will not work without it due to SIV /v2
.
The only pain points I've been experiencing is the tendency of the tools to automatically adding the go-fuzz module to Caddy's go.mod
and adding Caddy v1.0.3 to Caddy v2's go.sum
. I had to keep an eye on them and constantly revert them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we going to have to keep go.mod and go.sum maintained then, you think? Dang, I wish they'd make it work with modules... this might be kind of annoying.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure. Do you think this is a bug? Should it modify the root go.mod and go.sum with dependencies of the submodule?
It's ready for review. The only reason it's still marked as draft for now is because it needs one more commit to uncomment a few lines in the |
Okay, I have registered the Fuzzit API key with Azure Pipelines and uploaded the targets to Fuzzit. It should be ready to go I think! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The pipeline is ready to go. This PR looks good, just uncomment the env var bit and I'll probably approve this PR when the fuzzing works in CI. :)
fuzz/go.mod
Outdated
@@ -0,0 +1,10 @@ | |||
module local.tld/fuzz |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we going to have to keep go.mod and go.sum maintained then, you think? Dang, I wish they'd make it work with modules... this might be kind of annoying.
07a5122
to
c234ac1
Compare
Waiting on dvyukov/go-fuzz#263 |
Now I guess we're waiting on dvyukov/go-fuzz#274 ? |
For perfect solution? yes, I presume. However, mvdan is in the same boat as us, and he was able to do it without the temporary GOPATH (but still with the submodule) in this commit. I'll fiddle with it again this coming weekend. |
I really really don't want to do a submodule. I guess we can wait until they're ready to support modules. |
Note for later in case I forget: once go-fuzz gets proper module support, I don't think we'll need the |
Now that dvyukov/go-fuzz#274 is merged, I would be curious to hear if it works for you. ;-) |
displayName: 'Scheduled Fuzzing' | ||
# Only run this job on schedules, not PRs. | ||
condition: eq(variables['Build.Reason'], 'Schedule') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Azure Pipelines doesn't seem to support having a particular job on schedule while others triggered on PR, hence the condition.
@thepudds the latest |
Great! Thanks so much for all the work you put into this, @mohammed90 ! |
1. What does this change do, exactly?
Introduce fuzzers to Caddy's codebase for continuous fuzzing on CI. Closes #2710 .
2. Please link to the relevant issues.
#2710
3. Which documentation changes (if any) need to be made because of this PR?
N/A
4. Checklist