mirror of
https://github.com/opentffoundation/opentf.git
synced 2025-12-19 17:59:05 -05:00
Moved SBOM to a separate RFC
Signed-off-by: AbstractionFactory <179820029+abstractionfactory@users.noreply.github.com>
This commit is contained in:
AbstractionFactory
committed by
Martin Atkins
Martin Atkins
parent
a59608864a
commit
8f728cde15
@@ -10,65 +10,8 @@ This document is part of the [OCI registries RFC](../20241206-oci-registries.md)
|
||||
|
||||
As outlined in the [Design Considerations](3-design-considerations.md), we intend to start supporting the publication of SBOM artifacts. This requires changes to the existing OpenTofu registry and an extension to the [Provider Registry Protocol](https://opentofu.org/docs/internals/provider-registry-protocol/) and the [Module Registry Protocol](https://opentofu.org/docs/internals/module-registry-protocol/).
|
||||
|
||||
## Changes to the Provider Registry Protocol and the OpenTofu Registry
|
||||
The changes required to the registry are detailed in a separate RFC titled [Strengthening supply chain security: SBOMs and more](https://github.com/opentofu/opentofu/pull/2494).
|
||||
|
||||
To support SBOM artifacts, we are changing the ["Find a Provider Package"](https://opentofu.org/docs/internals/provider-registry-protocol/#find-a-provider-package) endpoint located at `:namespace/:type/:version/download/:os/:arch` to include the `attestations` field:
|
||||
|
||||
```json
|
||||
{
|
||||
"protocols": ["4.0", "5.1"],
|
||||
"os": "linux",
|
||||
"arch": "amd64",
|
||||
"filename": "terraform-provider-random_2.0.0_linux_amd64.zip",
|
||||
"download_url": "https://releases.example.com/terraform-provider-random/2.0.0/terraform-provider-random_2.0.0_linux_amd64.zip",
|
||||
"shasums_url": "https://releases.example.com/terraform-provider-random/2.0.0/terraform-provider-random_2.0.0_SHA256SUMS",
|
||||
"shasums_signature_url": "https://releases.example.com/terraform-provider-random/2.0.0/terraform-provider-random_2.0.0_SHA256SUMS.sig",
|
||||
"shasum": "5f9c7aa76b7c34d722fc9123208e26b22d60440cb47150dd04733b9b94f4541a",
|
||||
"signing_keys": {
|
||||
"gpg_public_keys": [
|
||||
{
|
||||
"key_id": "51852D87348FFC4C",
|
||||
"ascii_armor": "-----BEGIN PGP PUBLIC KEY BLOCK-----\nVersion: GnuPG v1\n\nmQENBFMO...",
|
||||
"trust_signature": "",
|
||||
"source": "ExampleCorp",
|
||||
"source_url": "https://www.examplecorp.com/security.html"
|
||||
}
|
||||
]
|
||||
},
|
||||
"attestations": [
|
||||
{
|
||||
"mediaType": "application/spdx+json",
|
||||
"name": "sbom.spdx.json",
|
||||
"url": "https://releases.example.com/terraform-provider-random/2.0.0/sbom.spdx.json"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
The OpenTofu Registry will, when scanning provider releases, identify the following file names as attestations and include their reference in the provider protocol responses.
|
||||
|
||||
- `*.spdx.json` (SPDX) will be identified as [`application/spdx+json`](https://www.iana.org/assignments/media-types/application/spdx+json)
|
||||
- `*.intoto.jsonl` ([in-toto attestation framework](https://github.com/in-toto/attestation), such as [SLSA Provenance](https://slsa.dev/spec/v1.0/provenance)) will be identified as `application/vnd.in-toto+json`.
|
||||
|
||||
Note, however:
|
||||
|
||||
- `*.spdx.xml` (SPDX) will *not* be supported until [there is an approved MIME type for it](https://github.com/spdx/spdx-spec/issues/577#issuecomment-960295523).
|
||||
- `bom.xml` and `bom.json` (CycloneDX) will *not* be supported [until there is an approved MIME type for it](https://github.com/CycloneDX/specification/issues/210).
|
||||
|
||||
> [!NOTE]
|
||||
> OpenTofu will not validate the contents of the attestations as there are too many possible formats to support. It is between the provider/module author and their community to ensure that the attestations are correct.
|
||||
|
||||
## Changes to the Module Registry Protocol and the OpenTofu Registry
|
||||
|
||||
Modules work differently to providers. Therefore, the module registry protocol will not be changed. However, when mirroring a module into an OCI registry, OpenTofu will consider the same file endings as described above **in the root directory only** as an SBOM artifact and include it in the OCI distribution.
|
||||
|
||||
## Changes to the HashiCorp providers
|
||||
|
||||
As part of the effort for supply chain security, OpenTofu will modify the [mirroring of HashiCorp providers](https://search.opentofu.org/docs/users/providers#using-hashicorp-maintained-providers-aws-azurerm-etc) to include generating an SPDX JSON SBOM document using [Goreleaser](https://goreleaser.com/customization/sbom/).
|
||||
|
||||
|
||||
> [!NOTE]
|
||||
> In an effort to support supply-chain security, we will also make these changes for the main OpenTofu release pipeline. The version including the OCI feature will also include an SBOM artifact.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -75,17 +75,7 @@ When necessary, you can attach artifacts containing signatures or attestations u
|
||||
> [!WARNING]
|
||||
> As of this RFC, OpenTofu will not use these artifacts directly, but may do so in a later version based on the MIME type. This section describes the files we intend to use for mirroring below, but will not otherwise process in this release.
|
||||
|
||||
Manifests attached to a single platform manifest:
|
||||
|
||||
- `terraform-provider-YOURNAME_VERSION_PLATFORM_ARCH.zip.gpg` as `application/pgp-signature` containing the GPG Signature of the ZIP file.
|
||||
- `terraform-provider-YOURNAME_VERSION_PLATFORM_ARCH.spdx.json` as `application/spdx+json` containing an SPDX SBOM file specific to this provider ZIP.
|
||||
- `terraform-provider-YOURNAME_VERSION_PLATFORM_ARCH.intoto.jsonl` as `application/vnd.in-toto+json` containing an [in-toto attestation framework](https://github.com/in-toto/attestation)/[SLSA Provenance](https://slsa.dev/spec/v1.0/provenance) file for the OS/architecture ZIP.
|
||||
|
||||
For the top level (index) manifest:
|
||||
|
||||
- `terraform-provider-YOURNAME.spdx.json` as `application/spdx+json` containing an SPDX SBOM file covering all OS/architecture combinations.
|
||||
- `terraform-provider-YOURNAME.intoto.jsonl` as `application/vnd.in-toto+json` containing an [in-toto attestation framework](https://github.com/in-toto/attestation)/[SLSA Provenance](https://slsa.dev/spec/v1.0/provenance) file covering all OS/architecture combinations.
|
||||
- `terraform-provider-YOURNAME_SHA256SUMS` as `text/plain`, containing the SHA256 checksums for the individual platform ZIP files. Additionally, `terraform-provider-YOURNAME_SHA256SUMS.gpg` may be attached to the current file as `application/pgp-signature`.
|
||||
Here we follow the naming in the [SBOM RFC](https://github.com/opentofu/opentofu/pull/2494) to determine which files are platform-dependent and which ones belong to the top-level manifest.
|
||||
|
||||
> [!WARNING]
|
||||
> Provider artifacts in OCI *must* have multi-platform (index) manifests. OpenTofu will refuse to download and use non-multi-platform artifacts as provider manifests. In contrast, [modules](6-modules.md) *must* have non-multi-platform manifests.
|
||||
@@ -99,7 +89,7 @@ Currently, there is no third-party tool capable of pushing an OCI artifact in th
|
||||
|
||||
In both cases we expect to find ZIP files that are [correctly named](https://search.opentofu.org/docs/providers/publishing#manually-for-the-adventurous) for providers, which will be published with individual multi-platform manifests. Additionally, the tool will process and upload any files matching file names described above.
|
||||
|
||||
The tool will also have a way to hook in external tools (such as [Syft](https://github.com/anchore/syft)) to generate SBOM files at the time of publication or mirroring.
|
||||
The tool will also have a way to hook in external tools (such as [Syft](https://github.com/anchore/syft)) to generate SBOM files at the time of publication or mirroring. The naming of the generated SBOM artifacts must match the naming in the [SBOM RFC](https://github.com/opentofu/opentofu/pull/2494).
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -17,7 +17,7 @@ module "foo" {
|
||||
}
|
||||
```
|
||||
|
||||
By default, this will inspect all of the tags whose name can be parsed as a semantic versioning-style version number, and select the one with the highest precedence according to [the semantic versioning specification](https://semver.org/). If there are multiple tags that all share the highest precedence, OpenTofu will prefer one without a build identifier segment if available, or will otherwise arbitrarily select the one whose build metadata would have the greatest precedence if treated as a prerelease identifier instead.
|
||||
By default, this will inspect all the tags whose name can be parsed as a semantic versioning-style version number, and select the one with the highest precedence according to [the semantic versioning specification](https://semver.org/). If there are multiple tags that all share the highest precedence, OpenTofu will prefer one without a build identifier segment if available, or will otherwise arbitrarily select the one whose build metadata would have the greatest precedence if treated as a prerelease identifier instead.
|
||||
|
||||
> [!NOTE]
|
||||
> Semantic versioning numbers may contain the `+` sign delimiting a build identifier, such as `1.1.0+something`. That character is not valid in an OCI reference, so OpenTofu will automatically translate the `_` symbol to `+` when attempting to parse a tag name as a version number.
|
||||
@@ -30,7 +30,7 @@ module "foo" {
|
||||
}
|
||||
```
|
||||
|
||||
Alternatively, you can specify a specific digest directly using the optional `digest` argument, which is mutually-exclusive with `tag`:
|
||||
Alternatively, you can specify a specific digest directly using the optional `reference` argument, which is mutually-exclusive with `tag`:
|
||||
|
||||
```hcl
|
||||
module "foo" {
|
||||
@@ -70,7 +70,6 @@ oras push \
|
||||
We also intend to provide a tool similar to how [providers work](5-providers.md) that will allow for publishing and mirroring modules. Similar to providers, the mirroring tool will attach detected SBOM and attestation artifacts to the modules in OCI. Specifically, the mirroring tool will detect:
|
||||
|
||||
- `*.spdx.json` as `application/spdx+json` containing an SPDX SBOM file.
|
||||
- `*.intoto.jsonl` as `application/vnd.in-toto+json` containing an [in-toto attestation framework](https://github.com/in-toto/attestation)/[SLSA Provenance](https://slsa.dev/spec/v1.0/provenance) file.
|
||||
|
||||
## OCI-based Modules through an OpenTofu Module Registry
|
||||
|
||||
@@ -84,6 +83,9 @@ For example, a module registry would be allowed to respond to such a request by
|
||||
|
||||
Such a design would use the module registry protocol to hide the implementation detail that the packages are actually coming from an OCI registry, but at the expense of needing to run an additional OpenTofu-specific module registry service. We do not currently anticipate this being a common need, but it is a natural consequence of the existing module registry protocol design.
|
||||
|
||||
> [!WARNING]
|
||||
> Classic OpenTofu Registry implementations should consider that references to OCI addresses will only work with OpenTofu version 1.10 and up. Older versions will be unable to access modules referenced in such a way.
|
||||
|
||||
---
|
||||
|
||||
| [« Previous](5-providers.md) | [Up](../20241206-oci-registries.md) | [Next »](7-authentication.md) |
|
||||
|
||||
Reference in New Issue
Block a user