sarif — archive
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]
RE: Relationship kinds
Yekaterina,
I took the directionality of the relationships from the definitions used by CodeSonar, as pasted by Paul into this
issue comment .
I agree that it is confusing, but (aside from the lateness of the hour), I don’t want the spec to have definitions that are the exact opposite of what CodeSonar uses.
Sorry for this,
Larry
From: [email protected] <[email protected]> On Behalf Of Yekaterina O'Neil
Sent: Friday, April 26, 2019 10:19 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: [sarif] RE: Relationship kinds
Caution: This email originated from outside the organization. Do not click links or open attachments unless you have verified this email is legitimate.
While in locationRelationship.kinds, the values identify relationship from theSource to theTarget (e.g. “includes” and “isIncludedBy”), it seems like in reportingDescriptorRelationship.kinds, the values don’t always identify relationship from theSource to theTarget, but raher from theTarget to theSource, and I find it confusing. For example, “superset” is defined to mean that theTraget is a superset of theSource, while to me it makes more sense to say that it means that “superset” = theSource is a superset of theTarget. Same goes for “subset”, “canFollow”, “canPrecede”, “willFollow”, and “willPrecede”. Perhaps, I am the only one who feels these are defined backwards?
k
From:
[email protected] [ mailto:[email protected] ] On Behalf Of Larry Golding (Myriad Consulting Inc)
Sent: Sunday, April 21, 2019 12:40 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: [sarif] RE: Relationship kinds
The change draft is available:
https://github.com/oasis-tcs/sarif-spec/blob/master/Documents/ChangeDrafts/Accepted/sarif-v2.0-issue-375-location-relationships.docx
… and I merged the changes into the always-up-to-date provisional draft:
https://github.com/oasis-tcs/sarif-spec/blob/master/Documents/ProvisionalDrafts/sarif-v2.0-csd02-provisional.docx
Thanks,
Larry
From:
[email protected] < [email protected]
> On Behalf Of Larry Golding (Myriad Consulting Inc)
Sent: Sunday, April 21, 2019 10:51 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
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]