Conversation
Five of the fourteen fuzz targets in the tree were missing from the scheduled job: FuzzVerify in auth/credential, FuzzDecrypt and FuzzEncryptDecrypt in auth/field, and FuzzVerify and FuzzVerifyRecoveryCode in auth/totp. All five belong to the three newest modules. Nothing went red over it. `go test` runs a fuzz target once over its seed corpus, so an unwired target still passes the suite and still reports as a test. The 60s budget, the mutation and the persisted corpus all live in the scheduled job, so those five had never been fuzzed at all. I added the five entries, and then a test that compares the tree against the workflow so the next module cannot repeat this. It parses the targets block with the standard library, since the block is a folded scalar holding JSON, so it adds no dependency. I checked it fails in the direction that matters: removing FuzzVerifyRecoveryCode from the workflow turns it red with the name of the target that stopped being fuzzed. Closes #343 Signed-off-by: Jose <75870284+Jaro-c@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Five of the fourteen fuzz targets in the tree were missing from
fuzz.yml:FuzzVerifyinauth/credential,FuzzDecryptandFuzzEncryptDecryptinauth/field, andFuzzVerifyandFuzzVerifyRecoveryCodeinauth/totp. All five belong to the three newest modules, which is to say the least reviewed code in the repository was also the code that was never fuzzed.Nothing went red over it, and that is the part worth fixing.
go testruns a fuzz target once over its seed corpus, so an unwired target still passes the suite and still reports as a test. The 60s budget, the mutation and the persisted per-target corpus all live in the scheduled job.So I added the five entries, and then a test that compares the tree against the workflow. It walks for functions named
Fuzz*taking a single*testing.Fand diffs that set against thetargetsblock, in both directions, so a target that is added without being wired fails on its own pull request, and an entry naming a target that no longer exists fails too. It parses the block withencoding/jsonrather than a YAML library, since the block is a folded scalar holding JSON, so it adds no dependency.I checked it fails in the direction that matters rather than assuming: removing
FuzzVerifyRecoveryCodefrom the workflow turns it red naming that target, and I confirmed the edit had actually changed the file before reading the red.Closes #343