Here is the net result of these two changes, as summarized in the
schema changes document. (The comments do not appear in the schema changes document.)
I am crafting a sample SARIF file to demonstrate all this, but I wanted to get this out to you ASAP.
Please take a look, because this is going to be a lot of writing!
Issue
#179: "Consider whether SARIF covers plug-ins/rules versioning sufficiently" and Issue
#311: "Provide full metadata objects for notifications"
NOTE: We describe the combined result of both of these changes, because both of them affect the location of rule metadata.
Rename the existing rule object
to reportingDescriptor.
// because it applies to notifications as well as results, now.
Rename the existing ruleConfiguration object
to reportingConfiguration
Define a toolComponent object
with the following properties:
·
All previously existing properties of the tool object except for language.
·
globalMessageStrings of type object with
property values of type string, moved and renamed from resources.messageStrings,
optional.
·
ruleDescriptors of type reportingDescriptor[],
moved and renamed from resources.rules, optional.
·
notificationsDescriptors of type reportingDescriptor[],
optional.
·
fileIndex of type integer, default:
-1, optional.
// so we can have information about the component like its file hashes and its location.
In the tool object:
·
Remove the sarifLoggerVersion property.
// Unrelated change. Michael invented it but never used it.
·
Move all remaining properties except for language into
the new toolComponent object.
·
Add a property driver of
type toolComponent, required.
·
Add a property extensions of
type toolComponent[], minItems:
0, unique, optional.
In the reportingDescriptor object
(renamed from rule):
·
Rename the configuration property
to defaultConfiguration.
In the reportingConfiguration object
(renamed from ruleConfiguration):
·
Rename the defaultLevel property
to level.
·
Rename the defaultRank property
to rank.
Define a reportingConfigurationOverride object
with the following properties:
·
ruleIndex of type integer,
optional, default: -1.
·
notificationIndex of type integer,
optional, default: -1. // Exactly one of ruleIndex and notificationIndex must
be present. This tells us whether we are configuring a rule or a notification.
·
extensionIndex of type integer,
optional, default: -1.
·
configuration of type reportingConfiguration,
required.
In the invocation object:
·
Add a reportingConfigurationOverrides property
of type reportingConfigurationOverride[], optional.
In the run object:
·
Remove the resources property.
Remove the resources object.
In the result object:
·
Add a property extensionIndex of
type integer, default:
-1, optional.
// goes along with ruleIndex so we can locate metadata for rules defined in an extension
In the conversion object:
·
Rename the tool property
to driver, and change its type from tool to toolComponent.
// name change for parallelism with
tool. Leaves open possibility that converters could have extensions in future.
Thanks,
Larry
From: <>
On Behalf Of Larry Golding (Myriad Consulting Inc)
Sent: Monday, February 11, 2019 5:32 PM
To: OASIS SARIF TC Discussion List <>
Subject: [sarif] Two unrelated issues in one change draft
For practical reasons, I’m going to produce a change draft that contains two seemingly unrelated changes:
Issue
#179: Consider whether SARIF covers plugins/rule versioning sufficiently.
Issue
#311: Provide full metadata objects for notifications.
The reason is that both of these changes have an effect on where the rule metadata ends up:
Issue #311 moves the rule metadata into the
tool object, but then…
Issue #179 breaks the
tool object into a set of
toolComponent objects…
… and the end result is that rule metadata ends up living in
toolComponent.
Since we agreed in principle to both of these changes during the F2F, I’m not worried about wasting effort by combining the drafts, and I think it will help you to see the overall result in a single draft. I should be able to get a draft
out by end of day tomorrow.
Thanks,
Larry
