semantic-conventions/model/artifact/registry.yaml

97 lines
4.3 KiB
YAML

groups:
- id: registry.artifact
type: attribute_group
brief: >
This group describes attributes specific to artifacts. Artifacts are
files or other immutable objects that are intended for distribution. This
definition aligns directly with the
[SLSA](https://slsa.dev/spec/v1.0/terminology#package-model) package
model.
attributes:
- id: artifact.filename
type: string
stability: experimental
brief: >
The human readable file name of the artifact, typically generated
during build and release processes. Often includes the package name
and version in the file name.
note: |
This file name can also act as the [Package Name](https://slsa.dev/spec/v1.0/terminology#package-model)
in cases where the package ecosystem maps accordingly.
Additionally, the artifact [can be published](https://slsa.dev/spec/v1.0/terminology#software-supply-chain)
for others, but that is not a guarantee.
examples:
[
"golang-binary-amd64-v0.1.0",
"docker-image-amd64-v0.1.0",
"release-1.tar.gz",
"file-name-package.tar.gz",
]
- id: artifact.version
type: string
stability: experimental
brief: >
The version of the artifact.
examples: ["v0.1.0", "1.2.1", "122691-build"]
- id: artifact.purl
type: string
stability: experimental
brief: >
The [Package URL](https://github.com/package-url/purl-spec) of the
[package artifact](https://slsa.dev/spec/v1.0/terminology#package-model)
provides a standard way to identify and locate the packaged artifact.
examples:
[
"pkg:github/package-url/purl-spec@1209109710924",
"pkg:npm/foo@12.12.3",
]
- id: artifact.hash
type: string
stability: experimental
brief: >
The full [hash value (see glossary)](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf),
often found in checksum.txt on a release of the artifact and used to
verify package integrity.
note: |
The specific algorithm used to create the cryptographic hash value is
not defined. In situations where an artifact has multiple
cryptographic hashes, it is up to the implementer to choose which
hash value to set here; this should be the most secure hash algorithm
that is suitable for the situation and consistent with the
corresponding attestation. The implementer can then provide the other
hash values through an additional set of attribute extensions as they
deem necessary.
examples:
["9ff4c52759e2c4ac70b7d517bc7fcdc1cda631ca0045271ddd1b192544f8a3e9"]
- id: artifact.attestation.id
type: string
stability: experimental
brief: >
The id of the build [software attestation](https://slsa.dev/attestation-model).
examples: ["123"]
- id: artifact.attestation.filename
type: string
stability: experimental
brief: >
The provenance filename of the built attestation which directly
relates to the build artifact filename. This filename SHOULD
accompany the artifact at publish time. See the
[SLSA Relationship](https://slsa.dev/spec/v1.0/distributing-provenance#relationship-between-artifacts-and-attestations)
specification for more information.
examples:
[
"golang-binary-amd64-v0.1.0.attestation",
"docker-image-amd64-v0.1.0.intoto.json1",
"release-1.tar.gz.attestation",
"file-name-package.tar.gz.intoto.json1",
]
- id: artifact.attestation.hash
type: string
stability: experimental
brief: >
The full [hash value (see glossary)](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf),
of the built attestation. Some envelopes in the software attestation
space also refer to this as the [digest](https://github.com/in-toto/attestation/blob/main/spec/README.md#in-toto-attestation-framework-spec).
examples:
["1b31dfcd5b7f9267bf2ff47651df1cfb9147b9e4df1f335accf65b4cda498408"]