sarif — archive
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]
RE: Relationship kinds
I placed the revised proposal in an
issue comment , including a revised sample, which I include here because I like it so much:
"results": [
{
"locations": [
{
"id": 0,
"physicalLocation": {
"artifactLocation": {
"uri": "f.h"
}
},
"relationships": [
{
"target": 1,
"kinds": [ "isIncludedBy" ]
}
]
}
],
"relatedLocations": [
{
"id": 1,
"physicalLocation": {
"artifactLocation": {
"uri": "g.h"
},
},
"relationships": [
{
"target": 0,
"kinds": [ "includes" ]
},
{
"target": 2,
"kinds": [ "isIncludedBy" ]
}
]
},
{
"id": 2
"physicalLocation": {
"artifactLocation": {
"uri": "g.c"
},
},
"relationships": [
{
"target": 1,
"kinds": [ "includes" ]
}
]
}
]
}
]
Larry
From: [email protected] <[email protected]> On Behalf Of Larry Golding (Myriad Consulting Inc)
Sent: Saturday, April 20, 2019 11:32 AM
To: OASIS SARIF TC Discussion List <[email protected]>
Cc: Harleen Kaur Kohli <[email protected]>; Michael Fanning <[email protected]>; James Kupsch <[email protected]>
Subject: [sarif] 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) < [email protected]
>
Sent: Friday, April 19, 2019 6:36 PM
To: Larry Golding (Myriad Consulting Inc) < [email protected] >; OASIS SARIF TC Discussion List < [email protected]
>
Cc: Harleen Kaur Kohli < [email protected] >; Michael Fanning < [email protected] >; James Kupsch < [email protected]
>
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:
[email protected] < [email protected]
> On Behalf Of Larry Golding (Myriad Consulting Inc)
Sent: Friday, April 19, 2019 6:32 PM
To: OASIS SARIF TC Discussion List < [email protected]
>
Cc: Harleen Kaur Kohli < [email protected] >; Michael Fanning < [email protected] >; James Kupsch < [email protected]
>
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:
[email protected] < [email protected]
> On Behalf Of Larry Golding (Myriad Consulting Inc)
Sent: Friday, April 19, 2019 5:49 PM
To: OASIS SARIF TC Discussion List < [email protected]
>
Cc: Harleen Kaur Kohli < [email protected]
>
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]
| [Month Index]
| [List Home]