This is a followup to our earlier RFC describing some drawbacks and
limitations of the current OpenTofu language runtime and proposing to move
to a new approach. Whereas the previous RFC primarily focused on defining
the problem, this document aims to propose the start of a solution, in
the form of a high-level architectural model that we can hopefully find
consensus on before we move on to discussing the associated implementation
details.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
While drafting this RFC originally I had intended to carve out an exception
of ignoring required_version arguments in .tf files while continuing to
support them in .tofu files, but apparently I lost that detail during some
copyediting and so the current draft implies that OpenTofu would continue
to use required_version in .tf files unless there's an OpenTofu-specific
declaration that takes precedence.
This update aims to clarify the proposal's handling of modules that are
written only for Terraform without using any OpenTofu-specific mechanisms:
in that case, we must just make a best effort to load the module in
OpenTofu and let it fail with a more specific error if the module happens
to be using language features that OpenTofu does not support, so that
loading can succeed when the module is only using the subset of features
that are cross-compatible between both systems.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
After adopting our original form of this policy we found out that GitHub's
security advisory feature will not allow us to publish "local-only"
advisories with no severity information, and instead sends copies of any
published advisory to other vulnerability databases. That is therefore not
a suitable way to handle false-positive reports, because distributing them
to other vulnerability databases would likely cause _even more_
false-positive reports from security scanners.
This therefore now describes the compromise we made in practice: we publish
our reasoning for classifying an advisory as false-positive in comments on
the relevant GitHub issue and then close that issue. This also mentions
our efforts to make these issues more discoverable by ensuring that the
advisory ID and affected module path are included in the summary of the
GitHub issue.
This is intended as a description of what we have already been doing in
practice, rather than as a proposal for a new policy.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
The original draft of this policy was written in future tense because we
had not begun following it yet. However, it makes more sense to write a
description of an active policy in present tense, so this retroactively
changes the existing sentences to make it clearer that this policy is
current rather than planned.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
The current OpenTofu language inherited a top-level block type named
"terraform" from its predecessor. Blocks of this type contain an
assortment of only-tangentially-related settings that seem to have ended
up there just because there wasn't any other obvious place to put them.
This document proposes new alternatives to those settings that are
intended to be tool-agnostic, while also making some room for other
changes we have already discussed including in future versions of the
language.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
A new approach to reporting provider package authentication results in the
getproviders package, which unifies the authentication result with the
"allowed hashes" and gives the provider installer more detail to use when
making other decisions based on the authentication results.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This includes both the "Module implementation details" appendix and a
general copyediting pass just to try to make the writing style a little
more consistent, since this content was originally written by two
different authors with different style preferences.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This now includes a summary of how we'll use a new implementation of
getproviders.Source to back the new oci_mirror provider installation
method, and how it can then interact internally with the ORAS-Go OCI
Distribution client.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This revises the previous content on implementation details related to the
cross-cutting authentication concerns to reflect our latest design, based
on a partial draft implementation.
These details still remain subject to change as we get into implementation,
but are included in the hope of helping with architectural-level discussion
of the implementation during the RFC process.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is an aggregated set of updates from feedback and discussion on the
previous draft. Unfortunately a significant change here is that we've
agreed to defer the SBOM question to a later project and so that entire
chapter is removed here, thereby renumbering all that came after it. I
tried to update all of the inter-chapter links, but I doubt I've found
all of them and will probably need to correct this more in future commits.
This first round of updates focuses on the main chapters and does not yet
update the appendices describing implementation details. I'll update the
appendices to match these latest updates in a future commit.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
In OpenTofu's current design, the "version" argument in a "module" block
is reserved for use only by the module registry protocol. Directly
specifying a remote source address does not allow that argument because
it delegates the installation process to go-getter, which has no concept
of versioning.
Therefore we'll start by following the existing precedent from existing
source address syntaxes like the one we use for Git repositories, where
the tag or digest is selected using URL query-string-style syntax.
In a later version of OpenTofu we might move to support "version" for
some of the remote source address syntaxes, at least including the "oci"
and "git" protocols. However, such a change is not in scope for the OCI
registry project because it would likely require a wholesale replacement
of go-getter with an API that better resembles our module registry client
API.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This commit rescopes what was originally a draft about provider
installation from OCI registries into a more general document about how
we intend to use OCI container images and OCI registries as a distribution
vehicle for at least two different kinds of OpenTofu dependency packages
(module and provider packages).
This document already had good content about how OCI registries and
artifacts work _in general_, and its associated PR was already attracting
general discussion about whether to use Docker-style or ORAS-style
conventions across both provider and module packages, so we'll now use
this document to discuss just the overall question of what style of
packaging we intend to use (across both package types) and will discuss
the module-specific and provider-specific details in other RFCs.
This also reworks the document to now propose using the Docker-like
conventions instead of the ORAS-like conventions, since that matches what
we've been exploring in prototypes. Of course, that decision is not final
until this RFC is accepted and merged, but we have considerably better
understanding of how this would work under the Docker-like approach than
ORAS and it seems like consensus is so far heading in that direction. We
may revise this document again if we learn of some strong arguments in
favor of the ORAS approach.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
