As discussed in opentofu/opentofu#2656, this consolidates the two concerns
of the PackageAuthentication interface into a single function that deals
both with package authentication _and_ with reporting all of the package
hashes that were used to make the authentication decision.
This means that any .zip archive that OpenTofu directly verifies during
installation can now have its hash recorded in the dependency lock file
even if that package didn't come from the provider's origin registry, which
is beneficial when the first installation of a provider comes from a
secondary ("mirror") source because it creates an additional hook by which
that dependency lock file entry can be "upgraded" to be complete in a
future "tofu init" run against the origin registry, or by the
"tofu providers lock" command.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
The initial design of this attempted to maximize our flexibility to make
backward-compatible changes to the manifest structure for providers in
future OpenTofu releases, by expecting the "layers" entry describing the
provider package to include a specific artifactType and ignoring any
layers with different artifactType values.
However, general-purpose tools for constructing image manifests don't tend
to allow setting the artifactType in a layer descriptor, so we'll drop
that requirement as a measure of pragmatism.
This implies that the only possible extension we could make for _layers
in particular_ in a future release is to support an additional archive
format that would presumably then be used in much the same way as our
current archive/zip usage: by extracting the archive into the target
directory. This ability to introduce new formats is the most likely future
evolution we identified while designing this, with all other evolutions
being more speculative/theoretical.
This does still retain various other extension points for future additions,
including but not limited to:
- Introducing an alternative artifactType for the image manifest _itself_,
rather than for the layers within it, and then having the later version
of OpenTofu prefer to choose a manifest with the newer artifactType while
still supporting the old one as a fallback.
- Using the "config" property of the manifest to introduce arbitrary
additional metadata that future versions might need, and using the
config descriptor's own mediaType to recognize when those new additions
are present.
Therefore this seems like a reasonable compromise to make it easier to
assemble OCI manifests for OpenTofu provider packages using general-purpose
tools like ORAS CLI, rather than requiring OpenTofu-specific tools.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is a new implementation of getproviders.Source that has a similar
purpose to HTTPMirrorSource but uses the OCI Distribution protocol instead
of the OpenTofu-specific Provider Mirror Protocol.
It translates OpenTofu-style provider source addresses into OCI repository
addresses using an externally-defined rule and then discovers provider
package metadata using the tags and associated manifests in the selected
repository.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is essentially a variation on PackageHTTPArchive that uses the
OCI Distribution protocol to retrieve a package from an OCI repository,
rather than directly from an HTTP URL.
It uses a similar technique of first downloading the package to a temporary
file and then delegating to the PackageLocalArchive location for the
final extraction, but it additionally verifies that the given OCI blob
descriptor seems reasonable and that the response matches the constraints
given in that descriptor.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
