RE: [sarif] More threadFlowLocation.kind values

["Larry Golding \(Comcast\)" <larrygolding@comcast.net>]

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?

 

Larry

 

From: O'Neil, Yekaterina Tsipenyuk <katrina@microfocus.com>
Sent: Monday, October 1, 2018 5:28 PM
To: Michael Fanning <Michael.Fanning@microsoft.com>; Larry Golding (Comcast) <larrygolding@comcast.net>; 'OASIS SARIF TC Discussion List' <sarif@lists.oasis-open.org>
Subject: RE: [sarif] More threadFlowLocation.kind values

 

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?

 

k

 

From: sarif@lists.oasis-open.org [mailto:sarif@lists.oasis-open.org] On Behalf Of Michael Fanning
Sent: Monday, October 01, 2018 3:35 PM
To: Larry Golding (Comcast) <larrygolding@comcast.net>; 'OASIS SARIF TC Discussion List' <sarif@lists.oasis-open.org>
Subject: RE: [sarif] More threadFlowLocation.kind values

 

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

 

entryPoint

unloadOrExit

 

âterminateâ might be another option.

 

 

 

From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> On Behalf Of Larry Golding (Comcast)
Sent: Monday, October 1, 2018 2:54 PM
To: 'OASIS SARIF TC Discussion List' <sarif@lists.oasis-open.org>
Subject: [sarif] More threadFlowLocation.kind values

 

Michael provided feedback on the change draft that restores threadFlowLocation.kind (Issues #194 and #202, pushed from TC #24 to TC #25 for lack of time):

 

Documents/ChangeDrafts/Active/sarif-v2.0-issues-194-202-threadFlowLocation-changes.docx

 

He requested some additional values:

 

• "applicationEntryPoint": This location is an entry point to the application.
• "applicationExit": This location is a point of exit from the application.
• "branchFalse": At this location, a branch in the execution path occurred because the branch condition evaluated to false.
• "branchTrue": At this location, a branch in the execution path occurred because the branch condition evaluated to true.
  NOTE: Plain âbranchâ still exists.
• "exceptionFilter": At this location, an exception filter was executed.

 

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.

 

Thanks,

Larry