jprdonnelly/opentf
1
0
Fork 0
mirror of https://github.com/opentffoundation/opentf.git synced 2025-12-19 17:59:05 -05:00
Code Issues Packages Projects Releases Wiki Activity

Navigation linking

Browse Source 
Signed-off-by: AbstractionFactory <179820029+abstractionfactory@users.noreply.github.com>
This commit is contained in:
AbstractionFactory
2025-02-07 14:53:35 +01:00
committed by Martin Atkins
parent 8f728cde15
commit fd95fa6a45
4 changed files with 21 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
rfc/20241206-oci-registries/10-provider-implementation-details.md
View File

@@ -32,3 +32,9 @@ OpenTofu's existing provider registry protocol always uses `.zip` archives as pr
We are not intending to support OCI artifact signing in our first implementation, since we are focusing initially only on the "OCI mirror" use-case. Without any signatures, we'll capture in the dependency lock file only the checksum of the specific artifact we downloaded, for consistency with the guarantees we make from installing from unsigned sources in today's OpenTofu. When we later add support for optionally signing the index manifest, we can begin using those signatures to justify including the `zh:` checksums from _all_ of the per-platform artifacts, announcing the ID of the signing key as part of the `tofu init` output just as we do for registry-distributed signatures today. It remains the user's responsibility to verify that the key ID is one they expected before committing the new checksums in the dependency lock file.
As with OpenTofu's current provider registry protocol, an OCI provider artifact cannot provide us any trustworthy representation of the `h1:` checksum of a provider package, and so OpenTofu will calculate that locally based on the already-downloaded package(s), assuming that they also match one of the previously-discovered `zh:` checksums, as usual.
---
| [« Previous](9-auth-implementation-details.md) | [Up](../20241206-oci-registries.md) | [Next »](10-provider-implementation-details.md) |
---

6
rfc/20241206-oci-registries/11-module-implementation-details.md
View File

@@ -14,3 +14,9 @@ This appendix discusses implementation details related to [installing module pac
> This section is still under construction, subject to change based on feedback on the earlier chapters, and may not yet be up-to-date with the latest changes in the earlier chapters.
> **TODO:** Write this!
---
| [« Previous](10-provider-implementation-details.md) | [Up](../20241206-oci-registries.md) |
---

4
rfc/20241206-oci-registries/8-open-questions.md
View File

@@ -4,7 +4,7 @@
This document is part of the [OCI registries RFC](../20241206-oci-registries.md).
| [« Previous](7-authentication.md) | [Up](../20241206-oci-registries.md) |
| [« Previous](7-authentication.md) | [Up](../20241206-oci-registries.md) | [Next »](9-auth-implementation-details.md) |
---
@@ -51,6 +51,6 @@ However, Punycode in particular is not generally human-readable and so translati
---
| [« Previous](7-authentication.md) | [Up](../20241206-oci-registries.md) |
| [« Previous](7-authentication.md) | [Up](../20241206-oci-registries.md) | [Next »](9-auth-implementation-details.md) |
---

8
rfc/20241206-oci-registries/9-auth-implementation-details.md
View File

@@ -4,7 +4,7 @@
This document is part of the [OCI registries RFC](../20241206-oci-registries.md).
| [Up](../20241206-oci-registries.md) | [Next »](10-provider-implementation-details.md) |
| [« Previous](8-open-questions.md) | [Up](../20241206-oci-registries.md) | [Next »](10-provider-implementation-details.md) |
---
@@ -56,3 +56,9 @@ To continue that evolution, we will extend `initwd.NewModuleInstaller` to also t
[`package main` directly instantiates `command.Meta`](https://github.com/opentofu/opentofu/blob/ffa43acfcdc4431f139967198faa2dd20a2752ea/cmd/tofu/commands.go#L89-L115) as its primary way of injecting dependencies into the CLI command layer, including the population of the `ProviderSource` field described above. We will therefore also pass the centrally-instantiated `getmodules.PackageFetcher` in the same way, completing the chain of dependency passing all the way from `package main` to the module installer.
The support for OCI registries as a module installation source will involve the addition of a new implementation of `go-getter`'s `Getter` interface, which will include the preconfigured `ociclient.OCIClient` as one of its fields. For more information, refer to [Module implementation details](11-module-implementation-details.md).
---
| [« Previous](8-open-questions.md) | [Up](../20241206-oci-registries.md) | [Next »](10-provider-implementation-details.md) |
---