pyjwt: improves code coverage

[jesslatimer]

This change adds;

• a fuzz corpus
• fuzzing for jwk
• each function consumes own data

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[jonathanmetzman]

@DavidKorczynski do you approve?

[DavidKorczynski]

I think in general when we go for making changes in existing fuzzers we should try to make it so existing seeds do not exhibit different behaviour. This PR and e.g #9967 does that -- could you perhaps address this (just in this PR not the ones that's merged) @jesslatimer ?

[DavidKorczynski]

Let's make payload and keyfile different (i.e different bytes for json.loads).

[jesslatimer]

I think in general when we go for making changes in existing fuzzers we should try to make it so existing seeds do not exhibit different behaviour. This PR and e.g #9967 does that -- could you perhaps address this (just in this PR not the ones that's merged) @jesslatimer ?

Not a problem at all, but could you please clarify what you would like changed @DavidKorczynski? Is the payload / keyfile an unrelated change? Sorry, still learning the ins and outs of fuzz testing.

[DavidKorczynski]

Not a problem at all, but could you please clarify what you would like changed @DavidKorczynski? Is the payload / keyfile an unrelated change? Sorry, still learning the ins and outs of fuzz testing.

The main point is to ensure a state where if the data buffer to the fuzzer entrypoint is the same as before this modification then the fuzzer should at least exercise the same code as before this modification. "At least the same" means that the code of the existing fuzzer should execute as before plus any additional new code. The reason for this is that otherwise existing bugs will not be reproducible and the existing corpus is likely not valid anymore.

The change in this fuzzer modification that causes this friction is that given the same data as prior to this modification, test_decoding and test_roundtrip will behave differently. Leaving the logic of those functions and how they're called and then using a similar strategy e.g. test_roundtrip_with_RS256(data) for the new targets would work well.