search

google / clusterfuzz

Scalable fuzzing infrastructure.
https://google.github.io/clusterfuzz
Apache License 2.0
5.27k stars 551 forks source link

Please clarify the inclusivity/exclusivity of fix revision ranges #2470

Open dsabsay opened 2 years ago

dsabsay commented 2 years ago

I searched the documentation site and the issues here but could not find a precise explanation of whether "fixed revision ranges" are inclusive, exclusive, or half inclusive/exclusive. By "fixed revision ranges" I am referring to what oss-fuzz provides when commenting that a particular test case has been verified as fixed (example).

Put another way, when the reported fixed range is e.g. foo:bar,

  1. If I checkout bar, do I have the fix?
  2. If I checkout foo, do I have the fix?

Clarifying this point would make it easier for consumers of these projects to ensure they have the patches.

oliverchang commented 2 years ago

Thanks for the feedback! This seems like a UX improvement we need to make on the ClusterFuzz side, so I'll move it there.

To answer your question, for a fixed range foo:bar, foo still crashes, but bar does not. If these are git commits, it's equivalent to saying the fix lies in the git range foo..bar.

dsabsay commented 2 years ago

I appreciate the clarification.

From my perspective, this could be addressed by either documentation or by changing the UI display. Something like Broken/Vulnerable in: foo, Fixed in: bar would leave much less guesswork for most users. Does the foo:bar syntax have any advantages I'm not seeing?