diff --git a/docs/_sass/minima/_layout.scss b/docs/_sass/minima/_layout.scss index a706c341b..7148a75d1 100644 --- a/docs/_sass/minima/_layout.scss +++ b/docs/_sass/minima/_layout.scss @@ -623,3 +623,8 @@ } } } + +.footnotes { + border-top: 1px solid $grey-border; + padding-top: $spacer-m; +} diff --git a/docs/github-actions-workflow/v0.1/example.json b/docs/github-actions-workflow/v0.1/example.json index 297a2a3b0..3aaa3058c 100644 --- a/docs/github-actions-workflow/v0.1/example.json +++ b/docs/github-actions-workflow/v0.1/example.json @@ -5,36 +5,30 @@ "buildType": "https://slsa.dev/github-actions-workflow/v0.1?draft", "externalParameters": { "inputs": { - "mapValue": { - "build_id": "123456768", - "deploy_target": "deployment_sys_1a", - "perform_deploy": "true" - } + "build_id": 123456768, + "deploy_target": "deployment_sys_1a", + "perform_deploy": "true" }, - "source": { - "artifactRef": { - "uri": "git+https://github.com/octocat/hello-world@refs/heads/main", - "digest": { "sha1": "c27d339ee6075c1f744c5d4b200f7901aad2c369" } - } + "vars": { + "MASCOT": "Mona" }, - "inputs": { - "mapValue": { - "mascot": "Mona" - } - }, - "workflowPath": { - "scalarValue": ".github/workflow/release.yml" + "workflow": { + "ref": "refs/heads/main", + "repository": "https://github.com/octocat/hello-world", + "path": ".github/workflow/release.yml" } }, "systemParameters": { "github": { - "mapValue": { - "actor": "MarkLodato", - "event_name": "workflow_dispatch" - } + "actor_id": "1234567", + "event_name": "workflow_dispatch" } }, "resolvedDependencies": [ + { + "uri": "git+https://github.com/octocat/hello-world@refs/heads/main", + "digest": { "sha1": "c27d339ee6075c1f744c5d4b200f7901aad2c369" } + }, { "uri": "https://github.com/actions/virtual-environments/releases/tag/ubuntu20/20220515.1" } diff --git a/docs/github-actions-workflow/v0.1/index.md b/docs/github-actions-workflow/v0.1/index.md index a8cc97eda..50be97039 100644 --- a/docs/github-actions-workflow/v0.1/index.md +++ b/docs/github-actions-workflow/v0.1/index.md @@ -9,87 +9,170 @@ hero_text: | ## Description This `buildType` describes the execution of a top-level [GitHub Actions] -workflow (as a whole). - -Note: This type is not meant to describe execution of subsets of the top-level -workflow, such as an action, a job, or a reusable workflow. - +workflow that builds a software artifact. + +Only the following [event types] are supported: + +| Supported event type | Event description | +| --------------------- | ----------------- | +| [`create`] | Creation of a git tag or branch. | +| [`deployment`] | Creation of a deployment. | +| [`release`] | Creation or update of a GitHub release. | +| [`push`] | Creation or update of a git tag or branch. | +| [`workflow_dispatch`] | Manual trigger of a workflow. | + +[`create`]: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#create +[`deployment`]: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#deployment +[`release`]: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#release +[`push`]: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#push +[`workflow_dispatch`]: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch + +This build type MUST NOT be used for any other event type unless this +specification is first updated. This ensures that the [external parameters] are +fully captured and that the semantics are unambiguous. Other event types are +irrelevant for software builds (such as `issues`) or have complex semantics that +may be error prone or require further analysis (such as `pull_request` or +`repository_dispatch`). To add support for another event type, please open a +[GitHub Issue][SLSA Issues]. + +Note: Consumers are REQUIRED to reject unrecognized external parameters, so new +event types can be added without a major version bump as long as they do not +change the semantics of existing external parameters. + +Note: This build type is **not** meant to describe execution of a subset of a +top-level workflow, such as an action, job, or reusable workflow. Only workflows +have sufficient [isolation] between invocations, whereas actions and jobs do +not. Reusable workflows do have sufficient isolation, but supporting both +top-level and reusable would make the schema too error-prone. + +[SLSA Issues]: https://github.com/slsa-framework/slsa/issues [GitHub Actions]: https://docs.github.com/en/actions +[event types]: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows +[isolation]: /spec/v1.0/requirements#isolation-strength ## Build Definition ### External parameters -All external parameters are REQUIRED unless empty. +[External parameters]: #external-parameters + +All external parameters are REQUIRED unless empty. At most one of `deployment`, +`inputs`, or `release` can be set.
ParameterTypeDescription -
inputsmapValue +
deploymentobject + +The non-default [deployment body parameters] for `deployment` events; unset for +other event types. SHOULD omit parameters that have a default value to make +verification easier. SHOULD be unset if there are no non-default values. + +Only includes the parameters that are passed to the workflow. As of API version +2022-11-28, this is: `description`, `environment`, `payload`, +`production_environment`, `transient_environment`. + +Can be computed from the [github context] using the corresponding fields from +`github.event.deployment`, filtering out default values (see API docs) and using +`original_environment` for `environment`. + +
inputsobject + +The `inputs` from `workflow_dispatch` events; unset for other event types. +SHOULD omit empty inputs to make verification easier. SHOULD be unset if there +are no non-empty inputs. + +Can be computed from the [github context] using `github.event.inputs`. + +
releaseobject -The [inputs context], with each value converted to string. Every non-empty input -value MUST be recorded. Empty values SHOULD be omitted. +The non-default [release body parameters] for `release` events; unset for +other event types. SHOULD omit parameters that have a default value to make +verification easier. SHOULD be unset if there are no non-default values. -Note: Only `workflow_dispatch` events and reusable workflows have inputs. +Only includes the parameters are passed to the workflow. As of API version +2022-11-28, this is: `body`, `draft`, `name`, `prerelease`, `target_commitish`. -
sourceartifact +Can be computed from the [github context] using the corresponding fields from +`github.event.release`, filtering out default values (see API docs). -The git repository containing the top-level workflow YAML file. +
varsobject -This can be computed from the [github context] using -`"git+" + github.server_url + "/" + github.repository + "@" + github.ref`. +The [variables] passed in to the workflow. This SHOULD be unset if there are no +vars. -
varsvars +Can be computed from the [vars context] using `vars`. -The [vars context], with each value converted to string. Every non-empty input -value MUST be recorded. Empty values SHOULD be omitted. +
workflowobject -
workflowPathstring +The workflow that was run. For most workflows, this commit is the source code to +be built. -The path to the workflow YAML file within `source`. +
workflow.refstring -Note: this cannot be computed directly from the [github context]: the -`github.workflow` context field only provides the *name* of the workflow, not -the path. See [getEntryPoint] for one possible implementation. +A git reference to the commit containing the workflow, as either a git ref +(starting with `refs/`) or commit ID (lowercase hex). This is the value passed +in via the event. Only `deployment` events support commit IDs. -[getEntryPoint]: https://github.com/slsa-framework/slsa-github-generator/blob/ae7e58c315b65aa92b9440d5ce25d795845b3b2a/slsa/buildtype.go#L94-L135 +Can be computed from the [github context] using `github.ref || github.sha`. + +
workflow.repositorystring + +HTTPS URI of the git repository, with `https://` protocol and without `.git` +suffix. + +Can be computed from the [github context] using +`github.server_url + "/" + github.repository`. + +
workflow.pathstring + +The path to the workflow YAML file within the commit. + +Can be computed from the [github context] using +`github.workflow_ref`, removing the prefix `github.repository + "/"` and the +suffix `"@" + github.ref`. Take care to consider that the path and/or ref MAY +contain `@` symbols.
+[deployment body parameters]: https://docs.github.com/en/rest/deployments/deployments?apiVersion=2022-11-28#create-a-deployment--parameters [github context]: https://docs.github.com/en/actions/learn-github-actions/contexts#github-context -[inputs context]: https://docs.github.com/en/actions/learn-github-actions/contexts#inputs-context +[release body parameters]: https://docs.github.com/en/rest/releases/releases?apiVersion=2022-11-28#create-a-release--parameters +[variables]: https://docs.github.com/en/actions/learn-github-actions/variables [vars context]: https://docs.github.com/en/actions/learn-github-actions/contexts#vars-context ### System parameters All system parameters are OPTIONAL. -| Parameter | Type | Description | -| -------------------- | -------- | ----------- | -| `github` | mapValue | A subset of the [github context] as described below. Only includes parameters that are likely to have an effect on the build and that are not already captured elsewhere. | - -The `github` map SHOULD contains the following elements: +| Parameter | Type | Description | +| --------- | -------- | ----------- | +| `github` | object | A subset of the [github context] as described below. Only includes parameters that are likely to have an effect on the build and that are not already captured elsewhere. | -| GitHub Context Parameter | Description | -| ------------------------------- | ----------- | -| `github.mapValue["actor"]` | The username of the user that triggered the initial workflow run. | -| `github.mapValue["event_name"]` | The name of the event that triggered the workflow run. | +The `github` object SHOULD contains the following elements: -> TODO: What about `actor_id`, `repository_id`, and `repository_owner_id`? Those -> are not part of the context so they're harder to describe, and the repository -> ones should arguably go on the `source` paramater rather than be here. -> -> Also `base_ref` and `head_ref` are similar in that they are annotations about -> `source` rather than a proper parameter. +| GitHub Context Parameter | Type | Description | +| ---------------------------- | ------ | ----------- | +| `github.actor_id` | string | The numeric ID of the user that triggered the initial workflow run. | +| `github.event_name` | string | The name of the event that triggered the workflow run. | +| `github.repository_id` | string | The numeric ID corresponding to `systemParameters.workflow.repository`. | +| `github.repository_owner_id` | string | The numeric ID of the user or organization that owns `systemParameters.workflow.repository`. | +| `github.triggering_actor_id` | string | The numeric ID of the user that triggered the rerun, if different than `actor_id`. | -> TODO: None of these are really "parameters", per se, but rather metadata -> about the build. Perhaps they should go in `runDetails` instead? The problem -> is that we don't have an appropriate field for it currently. +Numeric IDs are used here to provide stable identifiers across account and +repository renames and to detect when an old name is reused for a new entity. ### Resolved dependencies -The resolved dependencies MAY contain any artifacts known to be input to the -workflow, such as the specific versions of the virtual environments used. +The `resolvedDependencies` SHOULD contain an entry identifying the resolved +git commit ID corresponding to `externalParameters.workflow`. The dependency's +`uri` MUST be in [SPDX Download Location] format, i.e. +`"git+" + workflow.uri + "@" + workflow.ref`. See [Example]. + +The `resolvedDependencies` MAY contain additional artifacts known to be input to +the workflow, such as the specific versions of the virtual environments used. + +[SPDX Download Location]: https://spdx.github.io/spdx-spec/v2.3/package-information/#77-package-download-location-field ## Run details @@ -100,6 +183,8 @@ github.run_id + "/attempts/" + github.run_attempt`. ## Example +[Example]: #example + ```json {% include_relative example.json %} ``` diff --git a/docs/provenance/v1/index.md b/docs/provenance/v1/index.md index d7e959056..6de5ce2ce 100644 --- a/docs/provenance/v1/index.md +++ b/docs/provenance/v1/index.md @@ -60,14 +60,12 @@ The model is as follows: and need not be verified downstream. They MAY be included to enable reproducible builds, debugging, or incident response. - Some (but not all) parameters are references to artifacts. For example, the - external parameters for a GitHub Actions workflow includes the source - repository (artifact reference) and the path to the workflow file (string - value). - -- All other artifacts fetched during initialization or execution of the build - process are considered dependencies. The `resolvedDependencies` captures - these dependencies, if known. +- All artifacts fetched during initialization or execution of the build + process are considered dependencies, including those referenced directly by + parameters. The `resolvedDependencies` captures these dependencies, if + known. For example, a build that takes a git repository URI as a parameter + might record the specific git commit that the URI resolved to as a + dependency. - During execution, the build process MAY communicate with the build platform's control plane and/or build caches. This communication is not @@ -94,6 +92,11 @@ This predicate follows the in-toto attestation [parsing rules]. Summary: - Optional fields MAY be unset or null, and SHOULD be treated equivalently. Both are equivalent to empty for _object_ or _array_ values. +> **TODO:** The [GitHub Actions] spec says that consumers MUST **reject** +> unrecognized external parameters, whereas here we say that they MUST +> **ignore** unrecognized fields (including parameters). We need to figure out +> which is correct and then resolve the conflict. + ## Schema _NOTE: This section describes the fields within `predicate`. For a description @@ -156,14 +159,13 @@ Identifies the template for how to perform the build and interpret the parameters and dependencies. The URI SHOULD resolve to a human-readable specification that includes: overall -description of the build type; a list of all parameters (name, description, -external vs system, artifact vs scalar vs..., REQUIRED vs OPTIONAL, etc.); -unambiguous instructions for how to initiate the build given this -BuildDefinition, and a complete example. Example: +description of the build type; schema for `externalParameters` and +`systemParameters`; unambiguous instructions for how to initiate the build given +this BuildDefinition, and a complete example. Example: https://slsa.dev/github-actions-workflow/v0.1 externalParameters -map (string→ParameterValue) +object The parameters that are under external control, such as those set by a user or tenant of the build system. They MUST be complete at SLSA Build L3, meaning that @@ -176,7 +178,7 @@ Consumers SHOULD have an expectation of what "good" looks like; the more information that they need to check, the harder that task becomes. systemParameters -map (string→ParameterValue) +object The parameters that are under the control of the `builder`. The primary intention of this field is for debugging, incident response, and vulnerability @@ -187,9 +189,9 @@ already trusted, and in many cases it is not practical to do so. resolvedDependencies array (ArtifactReference) -Collection of artifacts needed at build time, aside from those listed in -`externalParameters` or `systemParameters`. For example, if the build script -fetches and executes "example.com/foo.sh", which in turn fetches +Unordered collection of artifacts needed at build time. Completeness is best +effort, at least through SLSA Build L3. For example, if the build script fetches +and executes "example.com/foo.sh", which in turn fetches "example.com/bar.tar.gz", then both "foo.sh" and "bar.tar.gz" SHOULD be listed here. @@ -200,13 +202,27 @@ all the information necessary and sufficient to initialize the build and begin execution. The `externalParameters` and `systemParameters` are the top-level inputs to the -template, meaning inputs not derived from another input. Each field is a map -from parameter name to [parameter value][ParameterValue]. The each parameter -name MUST be unique across `externalParameters` and `systemParameters`. The -following conventional names are RECOMMENDED when appropriate: +template, meaning inputs not derived from another input. Each is an arbitrary +JSON object, though it is RECOMMENDED to keep the structure simple with string +values to aid verification. The same field name SHOULD NOT be used for both +`externalParameters` and `systemParameters`. -- `source`: The primary input to the build. -- `config`: The build configuration, if different from `source`. +The parameters SHOULD only contain the actual values passed in through the +interface to the build system. Metadata about those parameter values, +particularly digests of artifacts referenced by those parameters, SHOULD instead +go in `resolvedDependencies`. The documentation for `buildType` SHOULD explain +how to convert from a parameter to the dependency `uri`. For example: + +```json +"externalParameters": { + "repository": "https://github.com/octocat/hello-world", + "ref": "refs/heads/main" +}, +"resolvedDependencies": [{ + "uri": "git+https://github.com/octocat/hello-world@refs/heads/main", + "digest": {"sha1": "7fd1a60b01f91b314f59955a4e4d4e80d8edf11d"} +}] +``` Guidelines: @@ -220,59 +236,52 @@ Guidelines: flags to live next to the source code or build configuration so that verifying the latter automatically verifies the compiler flags. +- In some cases, additional external parameters might exist that do not impact + the behavior of the build, such as a deadline or priority. These extra + parameters SHOULD be excluded from the provenance after careful analysis + that they indeed pose no security impact. + - If possible, architect the build system to use this definition as its sole top-level input, in order to guarantee that the information is sufficient to run the build. -- In some cases, the build configuration is evaluated client-side and - sent over the wire, such that the build system cannot determine its - origin. In those cases, the build system SHOULD serialize the - configuration in a deterministic way and record the `digest` without a - `uri`. This allows one to consider the client-side evaluation as a - separate "build" with its own provenance, such that the verifier can - chain the two provenance attestations together to determine the origin - of the configuration. - -**TODO:** Explain the purpose of `resolvedDependencies`. Why do we need it? What -goes in it? Is it OK for it to be incomplete? If a dependency is already pinned, -does it need to be listed? How does one choose between `resolvedDependencies` -and `builderDependencies`? - -### ParameterValue - -[ParameterValue]: #parametervalue - -REQUIRED: exactly one of the fields MUST be set. - -| Field | Type | Description | -| ----- | ---- | ----------- | -| `artifactRef` | [ArtifactReference] | Reference to an artifact. | -| `scalarValue` | string | Scalar value. | -| `mapValue` | map (string→string) | Unordered collection of name/value pairs. | -| `arrayValue` | array (string) | Ordered collection of values. | - -For simplicity, only string values or collections of string values are -supported. - -> ⚠ **RFC:** The design of parameters is still not settled. We welcome feedback -> on this particular design and suggestions for alternatives. In particular: -> -> - How restrictive ought we be? This is somewhat of a balance between making -> it easier for the builder vs [verifier][Verification]. A very restrictive -> type, such as only strings, makes it easier to set expectations but harder -> for a builder to describe reality. A very open type, such as an arbitrary -> JSON object, provides a lot of freedom to builders but possibly at the -> cost of complexity in terms of expectations. -> - Is there a better way to express types than using field names? -> - Do we need [ArtifactReference]? Would it instead make sense to just have -> the raw parameter here and then represent the digest in -> `resolvedDependencies`? What is the specific use case? -> -> Alternatives considered so far: -> -> - Only allow strings (difficult for many builders) -> - Allow strings, maps of strings, or arrays of strings (current design) -> - Allow arbitrary JSON (challenge: how do we do [ArtifactReference]?) +- When build configuration is evaluated client-side before being sent to the + server, such as transforming version-controlled YAML into ephemeral JSON, + some solution is needed to make [verification] practical. Consumers need a + way to know what configuration is expected and the usual way to do that is + to map it back to version control, but that is not possible if the server + cannot verify the configuration's origins. Possible solutions: + + - (RECOMMENDED) Rearchitect the build service to read configuration + directly from version control, recording the server-verified URI in + `externalParameters` and the digest in `resolvedDependencies`. + + - Record the digest in the provenance[^digest-param] and use a separate + provenance attestation to link that digest back to version control. In + this solution, the client-side evaluation is considered a separate + "build" that SHOULD be independently secured using SLSA, though securing + it can be difficult since it usually runs on an untrusted workstation. + +- The purpose of `resolvedDependencies` is to facilitate recursive analysis of + the software supply chain. Where practical, it is valuable to record the + URI and digest of artifacts that, if compromised, could impact the build. At + SLSA Build L3, completeness is considered "best effort". + +- It is acceptable for a single build service to have multiple modes of + operation, only some of which are SLSA-compatible. In this case, each mode + SHOULD have a separate `builder.id`. + +[^digest-param]: The `externalParameters` SHOULD reflect reality. If clients + send the evaluated configuration object directly to the build server, record + the digest directly in `externalParameters`. If clients upload the + configuration object to a temporary storage location and send that location + to the build server, record the location in `externalParameters` as a URI + and record the `uri` and `digest` in `resolvedDependencies`. + +> ⚠ **RFC:** We are particularly looking for feedback on this schema from +> potential implementers. Does this model map cleanly to existing build systems? +> Is it natural to identify and express the external parameters? Is anything +> confusing or ambiguous? ### ArtifactReference @@ -473,14 +482,18 @@ The timestamp of when the build completed. [Verification]: #verification -> **TODO:** Describe how clients are expected to verify the provenance. +> **TODO:** Describe how clients are expected to verify the provenance. This +> includes the idea that a verification tool can check external parameters +> without knowing the specific buildType. ## Index of build types The following is an partial index of build type definitions. Each contains a complete example predicate. -- [GitHub Actions Workflow](../../github-actions-workflow/v0.1/) +- [GitHub Actions Workflow] + +[GitHub Actions Workflow]: /github-actions-workflow/v0.1/ **TODO:** Before marking the spec stable, add at least 1-2 other build types to validate that the design is general enough to apply to other builders. @@ -496,37 +509,26 @@ The meaning of each field is unchanged unless otherwise noted. // The `buildType` MUST be updated for v1.0 to describe how to // interpret `inputArtifacts`. "buildType": /* updated version of */ old.buildType, - "externalParameters": old.invocation.parameters + { + "externalParameters": + old.invocation.parameters + { // It is RECOMMENDED to rename "entryPoint" to something more // descriptive. "entryPoint": old.invocation.configSource.entryPoint, - // OPTION 1: - // If the old `configSource` was the sole top-level input, - // (i.e. containing the source or a pointer to the source): - "source": { - "artifactRef": { - "uri": old.invocation.configSource.uri, - "digest": old.invocation.configSource.digest, - }, - }, - // OPTION 2: - // If the old `configSource` contained just build configuration - // and a separate top-level input contained the source: - "source": { - "artifactRef": old.materials[indexOfSource], - }, - "config": { - "artifactRef": { - "uri": old.invocation.configSource.uri, - "digest": old.invocation.configSource.digest, - }, - }, + // It is OPTIONAL to rename "source" to something more descriptive, + // especially if "source" is ambiguous or confusing. + "source": old.invocation.configSource.uri, }, "systemParameters": { "artifacts": null, // not in v0.2 "values": old.invocation.environment, }, - "resolvedDependencies": old.materials, + "resolvedDependencies": + old.materials + [ + { + "uri": old.invocation.configSource.uri, + "digest": old.invocation.configSource.digest, + } + ] }, "runDetails": { "builder": { @@ -568,19 +570,21 @@ Major refactor to reduce misinterpretation, including a minor change in model. - Altered the model slightly to better align with real-world build systems, align with reproducible builds, and make verification easier. - Grouped fields into `buildDefinition` vs `runDetails`. -- Renamed `parameters` and `environment` to `externalParameters` and - `systemParameters`, respectively. Both can now reference artifacts or string - values. -- Split and merged `configSource` into `externalParameters`. -- Split and merged `materials` into `resolvedDependencies`, - `externalParameters`, `systemParameters`, and `builderDependencies`. -- Added `localName`, `downloadLocation`, and `mediaType` to artifact - references. -- Removed `buildConfig`; can be replaced with - `externalParameters.artifacts["config"]`, `byproducts`, or simply omitted. -- Removed `completeness` and `reproducible`; now implied by `builder.id`. -- Added `builder.version`. -- Added `byproducts`. +- Renamed, with slight changes in semantics: + - `parameters` -> `externalParameters` + - `environment` -> `systemParameters` + - `materials` -> `resolvedDependencies` +- Removed: + - `configSource`: No longer special-cased. Now represented as + `externalParameters` + `resolvedDependencies`. + - `buildConfig`: No longer inlined into the provenance. Can be replaced + with a reference in `externalParameters` or `byproducts`, depending on + the semantics, or omitted if not needed. + - `completeness` and `reproducible`: Now implied by `builder.id`. +- Added: + - `localName`, `downloadLocation`, and `mediaType` + - `builder.version` + - `byproducts` ### v0.2 diff --git a/docs/provenance/v1/model.svg b/docs/provenance/v1/model.svg index 3050bbae1..31cfb29df 100644 --- a/docs/provenance/v1/model.svg +++ b/docs/provenance/v1/model.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/provenance/v1/provenance.cue b/docs/provenance/v1/provenance.cue index 20c406e4e..15636c982 100644 --- a/docs/provenance/v1/provenance.cue +++ b/docs/provenance/v1/provenance.cue @@ -8,8 +8,8 @@ "predicate": { "buildDefinition": { "buildType": string, - "externalParameters": { [string]: #ParameterValue }, - "systemParameters": { [string]: #ParameterValue }, + "externalParameters": object, + "systemParameters": object, "resolvedDependencies": [ ...#ArtifactReference ], }, "runDetails": { @@ -28,16 +28,6 @@ } } -#ParameterValue: { - "artifactRef": #ArtifactReference -} | { - "scalarValue": string -} | { - "mapValue": { [string]: string } -} | { - "arrayValue": [ ...string ] -} - #ArtifactReference: { "uri": string, "digest": { diff --git a/docs/provenance/v1/provenance.proto b/docs/provenance/v1/provenance.proto index f77ff8158..b727fa4df 100644 --- a/docs/provenance/v1/provenance.proto +++ b/docs/provenance/v1/provenance.proto @@ -16,19 +16,11 @@ message Provenance { message BuildDefinition { string build_type = 1; - map external_parameters = 2; - map system_parameters = 3; + google.protobuf.Struct external_parameters = 2; + google.protobuf.Struct system_parameters = 3; repeated ArtifactReference resolved_dependencies = 4; } -message ParameterValue { - // Logically a oneof, but oneof doesn't support repeated or map. - ArtifactReference artifact_ref = 1; - string scalar_value = 2; - map map_value = 3; - repeated string array_value = 4; -} - message ArtifactReference { string uri = 1; map digest = 2;