Make sure result.id explicitly notes its relevance to automation/results management systems

[michaelcfanning]

when a results management system returns a SARIF file, it may usefully decorate a result with an instance id of some kind. following the 'automationId' property that already exists in the log file (to allow correlation of a log file with a broader automation effort), we should provide an id slot for a results management system to pass an identifier that uniquely identifies the result. a SARIF consumer could then use the id in a call to the results management system to do things like mark it as a false positive.

we could call this thing the 'automationId' as well.

[michaelcfanning]

@lgolding we shouldn't have removed instanceId from the result object, need to restore.

[ghost]

@michaelcfanning ? We didn't remove it. It's defined in the spec (but we just called it result.id), and it hasn't yet been added to the SDK. See the mail I sent about the SDK: Issue #82, "Add instance id to the result object", is the first issue in chronological order that I hadn't yet gotten to.

[ghost]

@michaelcfanning Do you want to leave this issue open to track improvements to the text that describes result.id? If so, I'll change the title.

[michaelcfanning]

@lgolding yes. i went ahead and tweaked the title a bit.

[michaelcfanning]

we might want to make this thing (and other similar things) a guid instead of just an id.

[ghost]

@michaelcfanning Please read the existing text of §3.19.3, result.id property. It already discusses the relevance of this property to result management systems.

At some point -- I can't find the email -- we discussed separating the following two concepts:

1. Unique, permanent identification of a result in a result management system: handled by result.id -- as you said above, possibly as a GUID.
2. Identification of a result by way of a fingerprint: handled by the newly introduced result.fingerprints.

Now, the spec text still mixes these two concepts. It suggests three different ways to use result.id, two of which use it to hold a fingerprint.

I think I should do the following:

1. Remove the second and third bullet points -- the ones that suggest using result.id to hold a fingerprint.
2. Retain only the first bullet point -- the one that suggests a result-management-system-generated identifier -- and add text suggesting GUID as an example.

Do you agree?

[ghost]

@michaelcfanning I found the email:

Agreed the latter. Add both. 🙂

We should indicate that the instance is primarily intended to be populated by a result mgmt system that has ingested a result. It is to be used in many cases to allow update of the issue in the result mgmt system. The result producers populate the array of computed fingerprints.

This separation of purpose makes things clearer.

Get Outlook for iOS

---

From: Larry Golding (Comcast) larrygolding@comcast.net
Sent: Saturday, March 31, 2018 3:50:11 PM
To: Michael Fanning
Subject: #126: run.computedFingerprints[]

See my comment on this issue. Did we decide which way we’re going with this? Are we making run.id > an array, or adding run.computedFingerprints alongside run.id?

I vote for the latter. There are other uses for “id” than as a holder for a fingerprint. There’s nothing to stop a producer or a post-processor from populating run.id with a fingerprint, even if run.computedFingerprints also exists.

Larry

In it you agree with my proposal immediately above.

BUT! You wrote:

The result producers populate the array of computed fingerprints.

I don't think this is right. The result producer populates result.partialFingerprints. It's the result management system that populates result.fingerprints (a.k.a. "computed fingerprints").

Do you agree?

[michaelcfanning]

By result producer i meant 'the thing that automates the production of results'. The SARIF tool producer populates partialFingerprints. The broader thing (which you have more usefully named as the 'result management system' should populate fingerprints.

[ghost]

@michaelcfanning Perfect. Do you agree with the rest of what I wrote in the two comments preceding yours?

[ghost]

@michaelcfanning No, I'm being too reticent. Your email already did agree with what I wrote, and you clarified the only point of confusion, so I'll go ahead with this as the POR.

[ghost]

@michaelcfanning I'm writing this now. Following up on the comment above, I checked and the SDK does now define result.id.