[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sarif] More threadFlowLocation.kind values
We changed our mind because (Paul or Michael, correct me if I am wrong) Grammatech needed a property that could guide their toolâs UI to put icons in the margin indicating (for example), that a âtrueâ branch was taken.
You make an interesting point about âsanitizerâ: presumably, if a datum passes through a sanitizer, it will not trigger a result for âuse of tainted dataâ. But I can imagine a scenario where two pieces of tainted data enter the system and only one is sanitized 😊 So I think the âsanitizerâ kind could be useful.
As for a call to lambda, I donât know. Is it semantically different from a function call?
I was wondering in general why we changed our mind regarding the kind property (looks like I missed the discussion) â if I recall correctly, at the face-to-face meeting we agreed not to use this property.
Bu since we are working on the list, I am curious about why we have âsanitizerâ kind on the list, considering it will probably not be part of any result (result wonât be generated in this case). Or is the idea that it might be part of some informational result? On the other hand, why not add a âpassthroughâ kind to indicate that the taint was propagated at this location. Also, what about something like âendScopeâ to indicate the end of the variable scope? Finally, do we need a separate kind for lambda?
Iâd suggest making the first two concepts more generic. Entry points may occur at the driver or dynamic linked library level, for example, for some checkers. The following names might help make these a bit more general purpose
âterminateâ might be another option.
He requested some additional values:
Remember, the list is not meant to be exhaustive. The spec explicitly permits you to use any value you want if the defined values donât meet your needs.