OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sarif message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: Relationship kinds


After discussion with Michael: we believe that this change is both desirable from a design consistency standpoint, and in keeping with the spirit of what the TC approved. It does not add, delete, or change the semantics of any properties, it simply packages two of the properties into an object for consistency with what we did for reporting descriptor relationships.

 

So I will write the spec this way unless somebody objects (in which case, of course, we’ll discuss it).

 

Larry

 

From: Larry Golding (Myriad Consulting Inc) <v-lgold@microsoft.com>
Sent: Friday, April 19, 2019 6:36 PM
To: Larry Golding (Myriad Consulting Inc) <v-lgold@microsoft.com>; 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: 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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]