Advisories in the Go vulnerability database often identify specific Go
packages or even specific symbols within Go packages that the advisory
applies to.
Therefore when we are evaluating the impact of an advisory on OpenTofu we
often need to ask the question "what parts of OpenTofu are using that
affected package?"
This new tool is a small wrapper around the "go list" command which takes
a package path of interest and returns all of the packages in OpenTofu's
package import graph that directly import the given package. The results
can include both OpenTofu's own packages and packages from upstream modules
or the Go standard library.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
The upstream libraries we use to implement this feature are in various
states of unmaintained-ness where we've not been able to upgrade them
beyond the old versions we're currently using without them no longer
working well together.
Therefore we previously made this connection type produce a deprecation
warning in OpenTofu v1.12, and now we're making it produce an error instead
and so we can remove all of our code that was calling in to those
dependencies.
Although this is a breaking change, we're justifying it under the
"external dependencies" pragmatic exception in our compatibility promises:
external software has changed in a way that makes it no longer viable to
offer this feature. Modern Windows has built-in support for running an
OpenSSH server, and so we expect that most folks who were previously
relying on WinRM should be able to migrate to using SSH instead.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is just a minor release fixing a number of bugs that don't seem to
have affected OpenTofu, and so this is just a routine upgrade in
preparation for the v1.12.0 release.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is just a routine upgrade.
The upstream changes are mainly just robustness improvements, although
there is a notable fix in allowing "s3::http://..." addresses when the
specified hostname is not an official AWS hostname, whereas before the
S3 getter would just ignore the URL scheme and always use "https" behind
the scenes.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is just a routine upgrade. I have verified this against the acceptance
tests for both the "s3" backend and the "aws_kms" encryption key provider.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is just a routine upgrade. I've verified it by running the openbao
key provider's tests both in mock mode and in acceptance test mode against
a linux_amd64 build of OpenBao v2.5.1.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is just a routine upgrade in preparation for the v1.12.0 release.
I've verified this by running the acceptance tests against a linux_amd64
build of Consul v1.22.5.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is a routine upgrade. I have verified it by running the acceptance
tests for the "kubernetes" state storage implementation.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
OpenTofu still uses HCLv1 for the CLI Configuration, and unfortunately we
get ratcheted forward here onto the HashiCorp Vault-specific prereleases
of that old HCL version because our OpenBao keyprovider depends on the
OpenBao SDK, which indirectly depends on HCL.
In practice we're not actually using any part of the OpenBao SDK that
interacts with HCL, so this upgrade should not affect the OpenBao key
provider. It could potentially affect OpenTofu's CLI Configuration loader,
but the changes upstream are new functionality that OpenTofu won't use
and a fix to a bug related to the detection of unused arguments when
decoding into a Go struct type, neither of which should significantly
affect OpenTofu's behavior.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is just a routine upgrade. We already recently upgraded to the latest
available minor release, but since this is a security-sensitive dependency
I expect it'll be helpful to start our release period on the latest
available patch release.
This upgrade contains only a single change, which changes the behavior when
encountering an invalid elliptic curve key from a panic to an error result.
It should not affect the behavior for valid keys.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is just a routine upgrade in preparation for the v1.12 release series.
In an earlier commit we upgraded the main OpenTelemetry tracing modules to
latest, but left these contrib ones as-is because they had some shared
dependencies with other parts of OpenTofu that we wanted to upgrade first.
OpenTofu uses the "autoexport" library to handle the standard OpenTelemetry
environment variables for configuring trace collection, and the "otelhttp"
module for generating traces whenever OpenTofu makes an outgoing HTTP
request.
The "autoexport" library has a broad indirect dependency landscape because
it supports dynamic selection between a number of different OpenTelemetry
transport options. These indirect dependencies are not a significant part
of OpenTofu's functionality aside from tracing initialization.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is a routine upgrade. OpenTofu directly uses these libraries as part
of implementing the provider plugin protocol, but they are also used
indirectly by the libraries we use to interact with OpenTelemetry
collectors and some Google APIs and so the impact of upgrading these is
always quite tricky to evaluate.
However, I've reviewed the changes between these releases and it seems like
there are no behavior changes that would be significant for the use-cases
OpenTofu cares about. The gRPC library in particular has had a lot of
commits since we last upgraded it, but many of them are performance
improvements in the implementation details rather than significant behavior
changes.
This also includes the result of running "make protobuf" with the updated
version of the protobuf code generator, which for this release has merely
changed the version number recorded in the comments.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is just a routine upgrade. Upstream has added various new features but
all of them require opt-in either by explicit configuration or by using
new field types that were not previously supported at all, so they should
not immediately affect OpenTofu's behavior.
OpenTofu uses this library only in some legacy code that sticks around from
much older versions of its predecessor. Most uses of it were replaced by
HCL-based and cty-based equivalents a long time ago, but it sticks around
in the inline copy of the legacy plugin SDK used by the config decoding
logic from some state storage backends, and in some of the provisioner
configuration handling. These features only use very old, legacy parts of
the mapstructure library that have been preserved for
backward-compatibility.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is just a routine upgrade. The only upstream change that could affect
runtime behavior is a new option to disable matching hidden files, but
that's an opt-in so will not affect OpenTofu's behavior.
This library is used only as part of the implementation of the built-in
function "fileset", which returns a set of paths matching a given glob
pattern.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is just a routine upgrade. The Go project's ratcheting policy means
that we must also upgrade x/crypto, but that one doesn't have any changes
that are significant to OpenTofu.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Because the Go team always ratchets these all to depend on newer versions
of each other, it's not possible to upgrade these in isolation.
The main goal of this commit is to update all of the modules whose only
significant change is the dependency ratchet, in preparation for performing
more significant upgrades.
Unfortunately because many of these modules depend on x/tools, and x/tools
depends on x/net, there is no way to avoid performing a partial upgrade
of x/net. This is the smallest possible upgrade to that module to satisfy
the dependencies of the others I intend to make a followup commit focused
on x/net to bring it all the way to the latest available version.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is just a routine upgrade.
The latest version of go.opentelemetry.io/otel/sdk has adopted a newer
version of semconv and so this also updates our traceattrs package to
use the same version, as usual.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is just a routine upgrade. It contains a single fix for a panic bug
on invalid arguments to scrypt.Key.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is just a routine upgrade. There are absolutely no useful changes in
this release, but the Go team routinely just ratchets up the
interdependencies between the golang.org/x/* modules, and this one was
recently unblocked by us upgrading to golang.org/x/sys v0.42.0.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is just a routine upgrade.
Changes to this module are often tricky to review because OpenTofu's
relationship to most code in this module is very indirect, but from
studying the code diff carefully it doesn't seem like any changes here will
negatively impact OpenTofu's behavior.
This changeset includes some improvements to how supported CPU features are
detected on darwin_arm64 which may cause architecture-specific code in
some of our dependencies to perform better by using newer architecture
features, but I've not gone searching for any specific examples of that.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is just a routine upgrade to the latest available commit, just for
the sake of getting this off our list of available upgrades.
The only change here is from opentofu/registry-address#7, which is purely
a documentation update that doesn't affect the behavior.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Go team policy is to ratchet all of these together and so this is just the
usual periodic churn of updating all of the "easy" ones (the ones that
don't affect code that OpenTofu is directly using) to unblock later
upgrades of the ones that might require more intricate review.
All of the direct dependencies upgraded here feature only irrelevant
upgrades such as code modernization or new functionality that OpenTofu does
not currently import.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This also includes an upgrade to github.com/cloudflare/circl@v1.6.3, which
is newer than strictly required by go-crypto but includes the fix for a
security advisory that does not affect OpenTofu but would otherwise cause
false-positive reports because the Go vulnerability database entry for it
is too broad. The goal here is only to reduce false-positive scanner noise
for folks using the forthcoming v1.12.x series.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This includes the slight behavior change that an equality test with null
transfers only top-level marks to the resulting bool, and so in OpenTofu
an expression like foo != null where foo has a nested sensitive value
somewhere inside it will no longer produce a sensitive bool result, and
similarly for other marks that OpenTofu uses for various reasons.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Along with all of the usual purely-mechanical updates that we get from
these upgrades, these upgrades also introduce the ability for OpenTofu's
"s3" state storage backend to make use of credentials issued by the
"aws login" command recently added to the official AWS CLI.
Behind the scenes, this command uses OAuth to issue a refresh token, and
then the AWS SDK implementation uses that refresh token to request
time-limited session credentials. Successfully running "aws login" causes
there to be a new "login_session" setting in the AWS config file,
specifying which principal ARN was used to log in. Whenever that setting is
present, the SDK expects to find a valid refresh token in a new cache
directory kept in "~/.aws/login", and will fail if no valid token is
present in that cache directory.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is just a routine upgrade, with the intention that the forthcoming
OpenTofu v1.12 series will be based on this Go release series and so will
be under security support until February 2027 when this Go release will
cease to be supported.
As with the v1.11 series, we cannot predict exactly which day of February
Go 1.28 will be released on and so we'll be conservative and promise
support until the first day of that month, but in practice we're likely to
continue adopting relevant Go 1.26 minor releases for additional weeks of
February until the Go team stops publishing them.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
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>
