You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We need to support arbitrary metadata the user wants to associate with its release, like the version, arch, etc as part of the reusable workflow input arguments.
These input can be set in the package descriptor of the attestation. If we have to use purl to pack all this, we'll offload its computation to the caller using callback PURLToPackageDesc() and PackageDescToPURL(). We will need to reserve certain field names like environment to simplify verification by the deployment attestation (this is mostly relevant for containers)
The text was updated successfully, but these errors were encountered:
laurentsimon
changed the title
Rename environment and support version
Support arbitrary metadata in reusable workflow inputs
Mar 30, 2024
more generally, a reusable workflow takes as input:
package name
subjects, including their sha256. For containers, it's a single digest
package-metadata (version, arch, etc)
(1) and (3) are used to crate the package desc (in current code) or purl (if we switch to that).
(1) package is matched against the policy package name (without changes?)
(2) is used to populate the attestation subjects
We need to support arbitrary metadata the user wants to associate with its release, like the version, arch, etc as part of the reusable workflow input arguments.
These input can be set in the package descriptor of the attestation. If we have to use purl to pack all this, we'll offload its computation to the caller using callback
PURLToPackageDesc()
andPackageDescToPURL()
. We will need to reserve certain field names likeenvironment
to simplify verification by the deployment attestation (this is mostly relevant for containers)The text was updated successfully, but these errors were encountered: