Before Go 1.21 we relied on third-party and custom tooling to manage which
version of Go we were using for development, testing, and release builds.
However, modern Go toolchains have built-in support for selecting an
appropriate toolchain based on metadata in the go.mod file, and so we had
previously removed most uses of the .go-version file and were maintaining
it just as a remnant of the old state of things.
This replaces our last remaining use of the ".go-version" file with a small
tool that extracts the Go version from the go.mod file, and then removes
the ".go-version" file completely. The "go" and "toolchain" directives in
go.mod are now our single source of truth about which version of Go we're
currently using for OpenTofu.
(It may be possible to rework the Dockerfile for the consul backend to
handle Go version selection in a different way so that we'd no longer need
even this "selected-go-version" tool, but that's beyond the scope of this
commit which aims to leave it unmodified to make sure the effective testing
behavior for that backend is unchanged for now.)
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This minor revision includes a fix of a problem where a crafted zip file
can cause denial of service by taking a very long time to open the first
file in the archive, which can potentially be triggered by a
maliciously-crafted provider or module distribution archive fetched during
"tofu init".
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is just a routine upgrade that should not significantly change
OpenTofu's behavior because it only affects the websocket and http2 server
implementations. OpenTofu does not directly use websockets at all and only
uses http2 server as part of the temporary server used by "tofu login"'s
OAuth implementation, and even that uses the copy of this library vendored
into the Go standard library instead of through the module dependency.
Due to the Go team's policy of ratcheting dependencies between these
modules this also requires an upgrade of golang.org/x/crypto, but the only
change in that module is relevant only in "fips140=only" mode, which is
already not supported for OpenTofu for various other reasons.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This family of modules tend to ratchet forward their interdependencies even
when no upgrade is actually needed, so keeping the "easy" ones up to date
makes it more likely that we'd be able to upgrade the ones that require
more care and review if a security concern arises.
The four modules updated here only include interdependency ratchets and
changes to functionality that OpenTofu does not use, so this should not
affect OpenTofu's external behavior at all.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
We previously adopted the new "tools" mechanism for the third-party tools
we use for go:generate, etc. However, it's also acceptable to include tools
from our own module in this list, which then makes it possible to run them
using the same "go tool" shorthand.
For example, it's now possible to run "go tool protobuf-compile" to rebuild
the protocol buffers schemas, or "go tool tofu" as a shorthand way to
compile and run OpenTofu CLI itself.
It still remains possible to run these tools in the same ways they used to
work. This is just a new way to get the same results through a more modern
Go toolchain feature.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This version includes more complete support for the "!!merge" tag, which
now allows using a sequence of mappings instead of just a single mapping.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is just a routine upgrade. It should not significantly affect
OpenTofu's external behavior.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This upgrades both the OpenTelemetry SDK and all the base modules it
depends on, because things tend to work best when these are all upgraded
in lockstep to the same minor release.
Sometimes these upgrades also cause an indirect change to a newer version
of the OpenTelemetry "semconv" package which we then need to match in our
own traceattrs package, but no such change is required this time because
there has not been a new semconv version published in the meantime.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This updates only the base SDK module and the "smithy" helper library it
depends on. The service-specific functionality that OpenTofu uses is in
separate Go modules that are not upgraded yet here, because we'll want to
review their changes more closely in case they affect the behavior of our
S3 state storage or AWS KMS encryption features.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is a routine upgrade. The only change is a resynchronization of the
fallback bundle of trusted TLS certificates in x509roots, but OpenTofu
does not use of that bundle.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
These are just routine upgrades. None of the upstream changes here relate
to anything OpenTofu makes use of; the goal is just to get these
relatively-trivial upgrades out of the way because these x/* modules
tend to all ratchet forward together and so this clears the way for
upgrading others that might have more important changes later.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is just a routine dependency upgrade. Upstream there have been a few
small performance improvements that are unlikely to be particularly
beneficial to OpenTofu but shouldn't cause us any problems.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
We typically want our main branch to be on the latest Go release anyway,
but in this case we also intend to backport this to the v1.11 release to
patch GO-2025-4175, as discussed in opentofu/opentofu#3546.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is primarily to clear naive security scanner reports for GO-2025-4135,
which is a potential denial of service if attacker-controlled software can
send malformed packets back to OpenTofu through the SSH Agent proxy
channel.
We are not considering this a significant vulnerability for OpenTofu
because the SSH Agent forwarding pattern already assumes that software on
the remote system is trusted not to misuse the keys that are exposed though
the proxy channel.
Due to the Go team's policy of ratcheting upgrades between all of the
golang.org/x/* modules, this also requires upgrading three other modules.
I have reviewed the changes in those, and most appear to not affect
OpenTofu at all. There are some performance improvements to the HTTP2 and
QUIC implementations in x/net, but they don't seem to be a big concern for
us.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
The Go team tends to ratchet all of these libraries forward together even
if there have been no significant changes since the last release, and so
these three only include some fixes to typos in comments and test code
and some internal modernization to use the generic reflect.TypeFor instead
of the interface-based reflect.TypeOf.
Upgrading these should not affect OpenTofu's behavior in any material way,
and so this is just to get these easy ones out of the way before we deal
with the more significant changes in the other related modules that will
likely require closer review.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
In "package tofu" today we try to do everything using a generic acyclic
graph model and generic graph walk, which _works_ but tends to make every
other part of the problem very hard to follow because we rely a lot on
sidecar shared mutable data structures to propagate results between the
isolated operations.
This is the beginning of an experimental new way to do it where the "graph"
is implied by a model that more closely represents how the language itself
works, with explicit modelling of the relationships between different
types of objects and letting results flow directly from one object to
another without any big shared mutable state.
There's still a lot to do before this is actually complete enough to
evaluate whether it's a viable new design, but I'm considering this a good
starting checkpoint since there's enough here to run a simple test of
propagating data all the way from input variables to output values via
intermediate local values.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is just a routine upgrade, not expected to change the external
behavior of OpenTofu in any significant way.
However, notably the OpenTofu team does not currently have any way to run
the acceptance tests for this backend, so we cannot be sure that this won't
cause some kind of regression. I've reviewed the changes to these modules
as best I could from the Git history and it seems to be primarily
autogenerated API stub updates and a few small bugfixes, so I think the
risk is relatively low but there is nonetheless still some risk.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This also updates the other three k8s.io/* modules that we use, as
prerequisites for the upgrade.
The indirect dependency landscape for these modules has changed quite a lot
since the versions we were previously using, and so we have some new
indirect dependencies here. I quickly reviewed each of them and confirmed
that they seem to be under suitable licenses.
The k8s.io/utils/pointer package has been deprecated in favor of
k8s.io/utils/ptr, so this also updates our two callers of that to avoid
calling into deprecated functions.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
For some reason we had a few direct dependencies included in the "require"
clause for indirect dependencies. "go mod tidy" considers any directive
that contains a mixture of direct and indirect dependencies as
manually-edited and so avoids adding any new items to it, which was the
root cause of the repeated addition of a third "require" directive whenever
we made a change that caused a new indirect dependency to appear in this
file.
Moving these Azure-related direct dependencies into the first "require"
directive along with all of the other direct dependencies should hopefully
avoid that "go mod tidy" quirk occurring again under future maintenance.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This library is a dependency of our "postgresql" state storage
implementation.
This is just a routine upgrade to the latest available patch release. This
is mainly just a collection of minor upstream bugfixes and performance
improvements.
Notably this adds support for context.Context-based cancellation, though
that won't do anything in OpenTofu because we intentionally prevent
cancellation from reaching any of the state storage implementations so that
we can save new state snapshots even when other parts of OpenTofu are
shutting themselves down in response to a cancellation.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is just a routine upgrade, with no significant change in
functionality. It caused several indirect dependency changes too, but
they don't affect OpenTofu's main behavior.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is just a routine upgrade, bringing this last remaining OpenTelemetry
dependency up-to-date to match with the others we've upgraded recently.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
The Go 1.25.2 release included some new-strict validation of TLS
certificates that might potentially cause breakage for folks using private
PKI with OpenTofu.
Go 1.25.3 was an emergency patch release to re-weaken that validation back
to accepting what it used to accept and addressing the original motivating
vulnerabilities in a different way.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Although we usually prefer to upgrade in small units, in practice these
dependencies are all coupled together and relatively expensive to test, so
in this case it seems better to upgrade them all together and test them
all in a single set of acceptance test runs.
This is intended only as a routine upgrade, although upgrading the SDK is
often all that's needed to support any newly-added AWS regions or support
for existing services in additional regions, so this may expand the set
of regions that our AWS-integrated features can interact with.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is just a routine upgrade. We use this dependency only in our tests,
so this upgrade does not risk changing OpenTofu's behavior. There do not
seem to be any concerning changes upstream.
There are some systematic changes to the shape of the generated mock code,
with the results also included in this commit.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
My original intention was just to reduce our number of dependencies by
standardizing on a single comparison library, but in the process of doing
so I found various examples of the kinds of problems that caused this
codebase to begin adopting go-cmp instead of go-test/deep in the first
place, which make it easy to accidentally write a false-positive test that
doesn't actually check what the author thinks is being checked:
- deep.Equal silently ignores unexported fields, so comparing two values
that differ only in data in unexported fields succeeds even when it ought
not to.
TestContext2Apply_multiVarComprehensive in package tofu was an excellent
example of this problem: it had various test assertions that were
actually checking absolutely nothing, despite appearing to compare
pairs of cty.Value.
- deep.Equal also silently ignores anything below a certain level of
nesting, and so comparison of deep data structures can appear to succeed
even though they don't actually match.
There were a few examples where that problem had already been found and
fixed by temporarily overriding the package deep global settings, but
with go-cmp the default behavior already visits everything, or panics
if it cannot.
This does mean that in a few cases this needed some more elaborate options
to cmp.Diff to align with the previous behavior, which is a little annoying
but overall I think better to be explicit about what each test is relying
on. Perhaps we can rework these tests to need fewer unusual cmp options
in future, but for this commit I want to keep focused on the smallest
possible changes to remove our dependency on github.com/go-test/deep .
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
The changes to the core functionality since v1.9.3 seem to largely just
be internal changes such as adopting more modern functions from the Go
standard library. Most of the externally-visible changes were to
vendor-specific filesystem implementations that OpenTofu does not make any
use of, and so don't affect OpenTofu's behavior at all.
One notable change is that the upstream project has switched to a
multi-module structure where the vendor-specific filesystem implementations
that have special dependencies are each split into a separate Go module,
and so the root module now has far fewer direct dependencies, and that's
the cause of all of the deletions from our go.sum in this commit. The Go
toolchain is smart enough to know that we were not depending on the parts
of Afero that used those dependencies anyway and so they were not listed
in our go.mod, but it's still nice to remove a few items from the set
of dependencies the toolchain needs to probe when making installation
decisions.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
We were previously running a very old untagged commit of this module, and
the code in this module has been rearranged a lot in the meantime making
it hard to compare, but it seems like it's still implementing essentially
the same main functionality for tracing setup, just now extended for more
elaborate forms of the standard OpenTelemetry environment variables.
Unfortunately, the purpose of this module is to make dynamic runtime
decisions about exactly which transports to use and so this new version
brings in many additional indirect dependencies than before, most of which
are irrelevant for OpenTofu's current purposes because they related to
the logging and tracing parts of OpenTelemetry, whereas OpenTofu currently
focuses only on tracing. The logging and metrics part of OpenTelemetry were
still very early and experimental at the time of the commit we previously
depended on, and so it seems that the main upstream change here has been
improved support for those other use-cases. Most of these new indirect
dependencies are therefore unreachable at runtime by OpenTofu in practice.
For OpenTofu's purposes the only significant new capability here is to
set OTEL_TRACES_EXPORTER to "console" to write trace information to stdout,
but that remains unreachable in OpenTofu in practice because we currently
ignore that environment variable unless it is set to "otlp" exactly. We
could consider supporting "console" in a future release, but this mode
is questionable for OpenTofu because writing to stdout would interfere
with OpenTofu's main UI or machine-readable output. We'll wait for another
day to discuss the tradeoffs of that.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
The Go team uses automation to generate unnecessary version bumps across
all of these that make it impossible to upgrade them individually because
they all mutually depend on the latest versions of each other, so
unfortunately we have to accept the risk of updating all of these at once
in order to update any one of them.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Previously the Go toolchain had no explicit support for "tools" and so we
used the typical Go community workaround of adding "tools.go" files (two,
for some reason) that existed only to trick the Go toolchain into
considering the tools as dependencies we could track in go.mod.
Go 1.24 introduced explicit support for tracking tools as part of go.mod,
and the ability to run those using "go tool" instead of "go run", and so
this commit switches us over to using that strategy for everything we were
previously managing in tools.go.
There are some intentional exceptions here:
- The protobuf-compile script can't use "go tool" or "go run" because the
tools in question are run only indirectly through protoc. However, we
do still use the "tool" directive in go.mod to tell the Go toolchain that
we depend on those tools, so that it'll track which versions we are
currently using as part of go.mod.
- Our golangci-lint Makefile target uses "go run" to run a specific
version of golangci-lint. We _intentionally_ don't consider that tool
to be a direct dependency of OpenTofu because it has a lot of indirect
dependencies that would pollute our go.mod file. Therefore that continues
to use "go run" after this commit.
- Both of our tools.go files previously referred to
github.com/nishanths/exhaustive , but nothing actually appears to be
using that tool in the current OpenTofu tree, so it's no longer a
dependency after this commit.
All of the dependencies we have _only_ for tools are now classified as
"indirect" in the go.mod file. This is the default behavior of the Go
toolchain and appears to be motivated by making it clearer that these
modules do not contribute anything to the runtime behavior of OpenTofu.
This also corrected a historical oddity in our go.mod where for some reason
the "indirect" dependencies had been split across two different "require"
directives; they are now all grouped together in a single directive.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
We were previously using this module to access the then-experimental
"slices" package, but equivalent functionality is now available in a
standard library package so we no longer need to use the experimental
version.
This remains as an indirect dependency just because some of the tools we
use depend on it.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is just a routine upgrade, and doesn't change any functionality that
OpenTofu depends on. It includes a potential performance improvement for
comparisons between versions, and implementation of some
irrelevant-to-OpenTofu interfaces from the database/sql/driver package.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This upgrade includes some behavior changes that will affect OpenTofu's
handling of the TF_ARG_* environment variables, but in a generally positive
way: the parsing of those is now closer to how Unix shells typically
behave.
Although it's unlikely that this would affect anyone, it is technically a
behavior change that could potentially change the handling of some unusual
patterns such as empty arguments represented as pairs of quotes with
nothing between them.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This fixes some bugs that could potentially affect Windows users, though
they all appear to be unlikely problems that we've never had any reports
of from OpenTofu users, so this is mostly just a routine upgrade.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is just a routine upgrade. The upstream library contains no relevant
functional changes, just some different implementation details.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This release introduces an optional new backoff policy implementation, but
that is entirely new functionality that no OpenTofu caller uses and so
this should not cause any behavior changes.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This patch release includes an improvement to the error messages for
certain syntax errors involving "v" prefixes, which were previously
returning confusing error messages that misdiagnosed the problem.
There are no other behavior changes.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is a no-changes release that was generated by the Go team's upgrade
bot, which we're adopting here only because some of our other dependencies
require it but I want to upgrade those alone so we're not changing many
things all at once.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is an utterly pointless upgrade because it only modifies this module's
go.mod to require Go 1.24 instead of Go 1.23, but I'm upgrading it here
anyway because some of our other pending upgrades require this newer
version and I want to keep each of these upgrade PRs as small as possible.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
The 1.25.1 and 1.25.2 patch releases both include various security updates
that don't appear to directly affect OpenTofu, but nonetheless we'll
upgrade in preparation for our forthcoming v1.11.0 release so that these
advisories won't cause false-positives for imprecise security scanners
throughout our v1.11 series.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This includes a fix to a bug introduced in an earlier version of go-getter:
https://github.com/hashicorp/go-getter/pull/560
We did not actually use an affected version of go-getter in any stable
release yet, and so this change does not require a changelog update for
OpenTofu.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
