Skip to content

Commit

Permalink
Browse files Browse the repository at this point in the history
feat(ondemandscanning): update the api
#### ondemandscanning:v1

The following keys were added:
- schemas.BinarySourceInfo (Total Keys: 4)
- schemas.PackageData.properties.binarySourceInfo (Total Keys: 2)

#### ondemandscanning:v1beta1

The following keys were added:
- schemas.BinarySourceInfo (Total Keys: 4)
- schemas.PackageData.properties.binarySourceInfo (Total Keys: 2)
  • Loading branch information
yoshi-automation committed May 30, 2023
1 parent ced02fd commit e72efcc
Show file tree
Hide file tree
Showing 4 changed files with 76 additions and 10 deletions.
16 changes: 14 additions & 2 deletions docs/dyn/ondemandscanning_v1.projects.locations.scans.html
Expand Up @@ -100,7 +100,19 @@ <h3>Method Details</h3>
&quot;packages&quot;: [ # The packages to analyze.
{
&quot;architecture&quot;: &quot;A String&quot;, # The architecture of the package.
&quot;binaryVersion&quot;: { # The binary package. This is significant when the source is different than the binary itself. Historically if they&#x27;ve differed, we&#x27;ve stored the name of the source and its version in the package/version fields, but we should also store the binary package info, as that&#x27;s what&#x27;s actually installed. See b/175908657#comment15.
&quot;binarySourceInfo&quot;: [ # A bundle containing the binary and source information.
{
&quot;binaryVersion&quot;: { # The binary package. This is significant when the source is different than the binary itself. Historically if they&#x27;ve differed, we&#x27;ve stored the name of the source and its version in the package/version fields, but we should also store the binary package info, as that&#x27;s what&#x27;s actually installed. See b/175908657#comment15.
&quot;name&quot;: &quot;A String&quot;,
&quot;version&quot;: &quot;A String&quot;,
},
&quot;sourceVersion&quot;: { # The source package. Similar to the above, this is significant when the source is different than the binary itself. Since the top-level package/version fields are based on an if/else, we need a separate field for both binary and source if we want to know definitively where the data is coming from.
&quot;name&quot;: &quot;A String&quot;,
&quot;version&quot;: &quot;A String&quot;,
},
},
],
&quot;binaryVersion&quot;: { # DEPRECATED
&quot;name&quot;: &quot;A String&quot;,
&quot;version&quot;: &quot;A String&quot;,
},
Expand Down Expand Up @@ -128,7 +140,7 @@ <h3>Method Details</h3>
&quot;patchedCve&quot;: [ # CVEs that this package is no longer vulnerable to go/drydock-dd-custom-binary-scanning
&quot;A String&quot;,
],
&quot;sourceVersion&quot;: { # The source package. Similar to the above, this is significant when the source is different than the binary itself. Since the top-level package/version fields are based on an if/else, we need a separate field for both binary and source if we want to know definitively where the data is coming from.
&quot;sourceVersion&quot;: { # DEPRECATED
&quot;name&quot;: &quot;A String&quot;,
&quot;version&quot;: &quot;A String&quot;,
},
Expand Down
16 changes: 14 additions & 2 deletions docs/dyn/ondemandscanning_v1beta1.projects.locations.scans.html
Expand Up @@ -99,7 +99,19 @@ <h3>Method Details</h3>
&quot;packages&quot;: [ # The packages to analyze.
{
&quot;architecture&quot;: &quot;A String&quot;, # The architecture of the package.
&quot;binaryVersion&quot;: { # The binary package. This is significant when the source is different than the binary itself. Historically if they&#x27;ve differed, we&#x27;ve stored the name of the source and its version in the package/version fields, but we should also store the binary package info, as that&#x27;s what&#x27;s actually installed. See b/175908657#comment15.
&quot;binarySourceInfo&quot;: [ # A bundle containing the binary and source information.
{
&quot;binaryVersion&quot;: { # The binary package. This is significant when the source is different than the binary itself. Historically if they&#x27;ve differed, we&#x27;ve stored the name of the source and its version in the package/version fields, but we should also store the binary package info, as that&#x27;s what&#x27;s actually installed. See b/175908657#comment15.
&quot;name&quot;: &quot;A String&quot;,
&quot;version&quot;: &quot;A String&quot;,
},
&quot;sourceVersion&quot;: { # The source package. Similar to the above, this is significant when the source is different than the binary itself. Since the top-level package/version fields are based on an if/else, we need a separate field for both binary and source if we want to know definitively where the data is coming from.
&quot;name&quot;: &quot;A String&quot;,
&quot;version&quot;: &quot;A String&quot;,
},
},
],
&quot;binaryVersion&quot;: { # DEPRECATED
&quot;name&quot;: &quot;A String&quot;,
&quot;version&quot;: &quot;A String&quot;,
},
Expand Down Expand Up @@ -127,7 +139,7 @@ <h3>Method Details</h3>
&quot;patchedCve&quot;: [ # CVEs that this package is no longer vulnerable to go/drydock-dd-custom-binary-scanning
&quot;A String&quot;,
],
&quot;sourceVersion&quot;: { # The source package. Similar to the above, this is significant when the source is different than the binary itself. Since the top-level package/version fields are based on an if/else, we need a separate field for both binary and source if we want to know definitively where the data is coming from.
&quot;sourceVersion&quot;: { # DEPRECATED
&quot;name&quot;: &quot;A String&quot;,
&quot;version&quot;: &quot;A String&quot;,
},
Expand Down
27 changes: 24 additions & 3 deletions googleapiclient/discovery_cache/documents/ondemandscanning.v1.json
Expand Up @@ -339,7 +339,7 @@
}
}
},
"revision": "20230517",
"revision": "20230522",
"rootUrl": "https://ondemandscanning.googleapis.com/",
"schemas": {
"AliasContext": {
Expand Down Expand Up @@ -506,6 +506,20 @@
},
"type": "object"
},
"BinarySourceInfo": {
"id": "BinarySourceInfo",
"properties": {
"binaryVersion": {
"$ref": "PackageVersion",
"description": "The binary package. This is significant when the source is different than the binary itself. Historically if they've differed, we've stored the name of the source and its version in the package/version fields, but we should also store the binary package info, as that's what's actually installed. See b/175908657#comment15."
},
"sourceVersion": {
"$ref": "PackageVersion",
"description": "The source package. Similar to the above, this is significant when the source is different than the binary itself. Since the top-level package/version fields are based on an if/else, we need a separate field for both binary and source if we want to know definitively where the data is coming from."
}
},
"type": "object"
},
"BuildOccurrence": {
"description": "Details of a build occurrence.",
"id": "BuildOccurrence",
Expand Down Expand Up @@ -1750,9 +1764,16 @@
"description": "The architecture of the package.",
"type": "string"
},
"binarySourceInfo": {
"description": "A bundle containing the binary and source information.",
"items": {
"$ref": "BinarySourceInfo"
},
"type": "array"
},
"binaryVersion": {
"$ref": "PackageVersion",
"description": "The binary package. This is significant when the source is different than the binary itself. Historically if they've differed, we've stored the name of the source and its version in the package/version fields, but we should also store the binary package info, as that's what's actually installed. See b/175908657#comment15."
"description": "DEPRECATED"
},
"cpeUri": {
"description": "The cpe_uri in [cpe format] (https://cpe.mitre.org/specification/) in which the vulnerability may manifest. Examples include distro or storage location for vulnerable jar.",
Expand Down Expand Up @@ -1823,7 +1844,7 @@
},
"sourceVersion": {
"$ref": "PackageVersion",
"description": "The source package. Similar to the above, this is significant when the source is different than the binary itself. Since the top-level package/version fields are based on an if/else, we need a separate field for both binary and source if we want to know definitively where the data is coming from."
"description": "DEPRECATED"
},
"unused": {
"type": "string"
Expand Down
Expand Up @@ -339,7 +339,7 @@
}
}
},
"revision": "20230517",
"revision": "20230522",
"rootUrl": "https://ondemandscanning.googleapis.com/",
"schemas": {
"AliasContext": {
Expand Down Expand Up @@ -502,6 +502,20 @@
},
"type": "object"
},
"BinarySourceInfo": {
"id": "BinarySourceInfo",
"properties": {
"binaryVersion": {
"$ref": "PackageVersion",
"description": "The binary package. This is significant when the source is different than the binary itself. Historically if they've differed, we've stored the name of the source and its version in the package/version fields, but we should also store the binary package info, as that's what's actually installed. See b/175908657#comment15."
},
"sourceVersion": {
"$ref": "PackageVersion",
"description": "The source package. Similar to the above, this is significant when the source is different than the binary itself. Since the top-level package/version fields are based on an if/else, we need a separate field for both binary and source if we want to know definitively where the data is coming from."
}
},
"type": "object"
},
"BuildOccurrence": {
"description": "Details of a build occurrence.",
"id": "BuildOccurrence",
Expand Down Expand Up @@ -1746,9 +1760,16 @@
"description": "The architecture of the package.",
"type": "string"
},
"binarySourceInfo": {
"description": "A bundle containing the binary and source information.",
"items": {
"$ref": "BinarySourceInfo"
},
"type": "array"
},
"binaryVersion": {
"$ref": "PackageVersion",
"description": "The binary package. This is significant when the source is different than the binary itself. Historically if they've differed, we've stored the name of the source and its version in the package/version fields, but we should also store the binary package info, as that's what's actually installed. See b/175908657#comment15."
"description": "DEPRECATED"
},
"cpeUri": {
"description": "The cpe_uri in [cpe format] (https://cpe.mitre.org/specification/) in which the vulnerability may manifest. Examples include distro or storage location for vulnerable jar.",
Expand Down Expand Up @@ -1819,7 +1840,7 @@
},
"sourceVersion": {
"$ref": "PackageVersion",
"description": "The source package. Similar to the above, this is significant when the source is different than the binary itself. Since the top-level package/version fields are based on an if/else, we need a separate field for both binary and source if we want to know definitively where the data is coming from."
"description": "DEPRECATED"
},
"unused": {
"type": "string"
Expand Down

0 comments on commit e72efcc

Please sign in to comment.