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.
Parameter
Type
Description
-
inputs
mapValue
+
deployment
object
+
+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`.
+
+
inputs
object
+
+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`.
+
+
release
object
-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`.
-
source
artifact
+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.
+
vars
object
-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.
-
vars
vars
+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.
+
workflow
object
-
workflowPath
string
+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.ref
string
-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.repository
string
+
+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.path
string
+
+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
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.
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.
-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;