These fixes came from opentofu/opentofu#3467, but that PR is just upgrading
Go and so does not contain any directly-useful context.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is to address the upstream security advisory GO-2025-4014, although
it also incidentally deals with several other advisories published on the
same day: GO-2025-4007, GO-2025-4008, GO-2025-4009, GO-2025-4010,
GO-2025-4011, GO-2025-4012, and GO-2025-4013.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
The code for matching relevant_attributes against resource_drift entries
(a part of the heuristic for deciding whether to show "changes outside of
OpenTofu" in the human-oriented plan UI) was previously assuming that paths
in resource_drift would always be valid for the associated resource
instance object values because in most cases the language runtime will
detect invalid references and so fail to generate a plan at all.
However, when the reference is to something within a dynamically-typed
argument (such as the manifest in kubernetes_manifest) and when it appears
only as an argument to either the "try" or "can" functions (so the dynamic
error is intentionally suppressed) the language runtime can't catch it
and so the incorrect reference will leak out into relevant_attributes,
thereby violating assumptions made by the path matcher.
Instead then, we'll continue the existing precedent that this "relevant
attributes" mechanism is a best-effort heuristic that prefers to succeed
with an incomplete result rather than to fail, extending that to the
traversals in the plan renderer which will now treat incorrectly-typed
steps as not matching rather than causing OpenTofu to crash completely.
Since a reference to something that doesn't exist cannot succeed it also
cannot possibly _actually_ contribute directly to the final result of the
expression it appeared in, so in practice it should be okay to disregard
these invalid references for the purposes of deciding which changes outside
of OpenTofu seem likely to have caused the actions that OpenTofu is
proposing to make during the apply phase.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Previously we generated some logs during the discovery process indicating
which locations OpenTofu was probing for ambient credentials, but we didn't
explicitly report the overall result of the discovery process.
These new log lines will now report the final effective set of credential
configuration locations just before we try to use them in either the
provider installation or module installation codepaths. The strings
returned by CredentialsConfigLocationForUI are intended for just this sort
of feedback: the exact format varies for each kind of location, but it's
always a concise string identifying a location that OpenTofu will consider
when attempting to decide credentials.
Logging this here does unfortunately mean that the log output will be
repeated for each separate OCI registry request. There not being a great
single location to generate these logs was the main reason we didn't
include something like this in the first implementation, but the set of
config locations is small on any reasonable system and we've already had
a few folks struggle to understand why OpenTofu is making a certain
decision about credential sources so this is a pragmatic small step to give
us some extra diagnostic information in bug reports without affecting the
normal UI output for now.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Recently we added a call to Locks.UpgradeFromPredecessorProject to try to
preserve dependency selections made for providers under
registry.terraform.io/hashicorp/* when switching to OpenTofu for the first
time.
However, this behavior did not properly cater for the situation where the
configuration intentionally specifies registry.terraform.io explicitly in
a source address: that would then cause OpenTofu to incorrectly try to make
a factory function for the shimmed provider version when working in
command.Meta.providerFactories, which would then fail because no such
provider appears in the cache directory.
Instead then, we'll limit the shimming only to installation-related actions
while only using the dependency locks exactly as written when preparing to
actually _run_ the provider plugins.
This is bothersome to test because our tests are not allowed to directly
access registry.terraform.io; the test case here mimicks one case in which
it could be valid for an OpenTofu user to explicitly use
registry.terraform.io: if they've used the CLI configuration to arrange for
that hostname to be handled only via a mirror rather than by direct access
to the origin registry. The terms of service for registry.terraform.io
currently prohibit using it for anything other than Terraform, so we ensure
that this test cannot make requests to any real services at that hostname.
Note that telling OpenTofu to use registry.terraform.io is not officially
supported and may cause other problems beyond what was addressed by this
PR, since OpenTofu tends to assume that this hostname would appear only
during the process of migrating from Terraform and might make unexpected
decisions based on that assumption. Despite us making this fix, those who
are explicitly specifying registry.terraform.io in their configuration
should make plans to stop doing that and to set things up some other way
instead.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
