RE: Relationship kinds

Let me modulate my message there. The two designs are indeed not consistent, and one way to make them consistent – if we think that’s desirable – is what I described. But I make no proposal about what, if anything, we should do about it.

Larry

From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> On Behalf Of Larry Golding (Myriad Consulting Inc)
Sent: Friday, April 19, 2019 6:32 PM
To: OASIS SARIF TC Discussion List <sarif@lists.oasis-open.org>
Cc: Harleen Kaur Kohli <harleen.kohli@microsoft.com>; Michael Fanning <Michael.Fanning@microsoft.com>; James Kupsch <kupsch@cs.wisc.edu>
Subject: [sarif] RE: Relationship kinds
Importance: High

Oooh! Let’s define "relevant" like we did for reportingDescriptorRelationship.kinds so that – again, like reportingDescriptorRelationship.kinds –the default for location.relationshipKinds is [ "relevant" ].

Having done that – and it hurts me to say this – I see that our location relationship design is inconsistent with our reporting descriptor relationship design. We should have done this for consistency:

Define an object locationRelationship with these properties:

target of type integer, required, minValue: 0
kinds of type string[], optional, default: [ "relevant" ].

In the location object:

Add a property id of type integer, optional, minValue: -1, default: -1 (no change from current design – relocated from physicalLocation)
Add a property relationships of type locationRelationship[], optional, default: [].

In the physicalLocation object:

Remove the id property (no change from current design – moved to location)

Sorrier than I can say (and only partially facetious about that),

Larry

From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> On Behalf Of Larry Golding (Myriad Consulting Inc)
Sent: Friday, April 19, 2019 5:49 PM
To: OASIS SARIF TC Discussion List <sarif@lists.oasis-open.org>
Cc: Harleen Kaur Kohli <harleen.kohli@microsoft.com>
Subject: [sarif] Relationship kinds

As part of our acceptance of #375 (location relationships), I took an action to drive a mailing list discussion about values for location.relationshipKinds, beyond the two values "includes" and "isIncludedBy" that the issue defines.

So… any ideas? I will take 30 seconds now to ponder…

Some taint-related values? Like "isSourceOfTaintedDataUsedBy", "isSinkForTaintedDataUsedBy", and "sanitizesTaintedDataUsedBy". (pretty verbose, but I wanted to be clear about the relationships).

Thanks,

Larry

sarif message