Integrate initial OSS-Fuzz support

[initializedd]

Please complete the following tasks

• I have searched the discussions
• I have searched the open and rejected issues

Clap Version

master

Describe your use case

Initial support for fuzzing clap to discover and fix bugs.

If my fuzzer is merged, I will open a pull request in the OSS-Fuzz repository to run the fuzzers for this library on Google's infrastructure. Maintainers of clap will be notified if any bugs are discovered.

Please see the OSS-Fuzz documentation and Bug disclosure guidelines before merging.

Thanks!

Describe the solution you'd like

PR #5851

Alternatives, if applicable

No response

Additional Context

No response

[epage]

I've wondered about fuzzing but whats not too clear to me is what would provide the best value, or in other words, what are the high risk areas. Like in #5851, its parsing strings (not OsStrings) against a limited, static CLI definition. I feel like this is unlikely to uncover anything of interest.

[initializedd]

I've wondered about fuzzing but whats not too clear to me is what would provide the best value, or in other words, what are the high risk areas. Like in #5851, its parsing strings (not OsStrings) against a limited, static CLI definition. I feel like this is unlikely to uncover anything of interest.

Thanks for your response.

I agree that the fuzzer in #5851 is unlikely to uncover anything of interest, but I’d like to emphasize that that this is more about integrating OSS-Fuzz support than the specific fuzzers themselves at this stage. We need to ensure that we have the necessary approvals from both parties before diving deep into the fuzzers. The aim is to eventually reach 100% fuzzing coverage through an iterative process of constant refinement.

I've updated #5851 to parse OsStrings instead.

I am open to any further suggestions you may have.

[epage]

An OsString from a String doesn't make much of a difference.

For me, the big question is "will this be worth it" which is dependent on what a proposed fuzzer looks like.

[popematt]

@initializedd, I'm sorry, I over-reacted based on my own bad experience with some unknown 3rd party actor. I realize now that it sounds like I am accusing you of malicious behavior. I know nothing about you, and so I cannot fairly comment on your intentions. In retrospect, I don't think my original comment has any value, so I will delete it.

[initializedd]

@initializedd, I'm sorry, I over-reacted based on my own bad experience with some unknown 3rd party actor. I realize now that it sounds like I am accusing you of malicious behavior. I know nothing about you, and so I cannot fairly comment on your intentions. In retrospect, I don't think my original comment has any value, so I will delete it.

Thanks for understanding.

@epage Are there any specific examples that you would suggest drawing inspiration from to improve the proposed fuzzer?

[epage]

I don't know of an example that would be relevant for fuzzing. What I'm asking of you is to propose fuzzing that would provide enough value to be worth it.

[initializedd]

@epage Apologies for my absence.

I am still keen to integrate fuzzing support for your library.

I've taken a further look at the codebase, and it seems to me that we will get the most value out of this by fuzzing the internal functions. Usages of unsafe (although few in the codebase) should probably be prioritized for extra assurance.

Some ideas of internal functions that we could start with:

• is_number
• is_negative_number
• strip_prefix
• split_once
• split_at
• next_value_os

Absolutely happy to implement support for all of those (providing that you agree), and any more that you think would be good.

[epage]

Note that the goal for any of those ext.rs functions is for them to be moved into std and for us to use that, see rust-lang/libs-team#311

clap_lexs public API is a possibility, depending on what the fuzzing would like.