We're intending to explicitly document the end of support for each of our
release series moving forward, starting with the v1.11.x series here.
This seemingly-arbitrary cutoff is actually aligned with the date when
Go v1.25 is expected to reach end of security support, since we cannot
feasibly provide security support longer than the language and standard
library that OpenTofu's functionality depends on.
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>
Unfortunately the Go team has unilaterally decided that all programs built
with Go 1.24 and later always allow enabling FIPS-140-3 mode -- both in
its "on" and "only" configurations -- regardless of whether the authors
of that software intend to support running in that restricted mode, or
whether they are even testing their application in that configuration.
We have not yet made a final decision on how and whether we intend to
support this mode in our official builds, but we _do_ know that OpenTofu
cannot currently function correctly with this mode enabled because it
relies on standard library features and external libraries that are not
available in that case.
Therefore in the meantime we'll mention explicitly in both the internal
logs and in the "tofu version" output if we appear to be running in that
mode, meaning that if someone tries to use it and finds that it doesn't
work properly then if they open a GitHub issue and share those two
artifacts (as requested by our bug report template) then we can know that
we might need to turn on the special mode in order to reproduce the
reported problem, rather than wasting time trying to reproduce it in the
standard mode.
We do still need to make a final decision about what we want to do with
this in the long run, but this is intended as an short-term compromise
that allows folks to experiment with this unsupported mode if they wish
while hopefully making it clearer that in the mean time we may
deprioritize fixing problems that only occur when this unusual mode is
enabled.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Signed-off-by: Christian Mesh <christianmesh1@gmail.com>
The new SDK version we adopted includes new definitions required to support
the eusc-de-east-1 retion, and so this upgrade should be sufficient for
the "s3" state storage backend to work with S3 buckets in that region.
Note that this region is part of the new separate European partition of
AWS, rather than the main commercial partition that's simply called "aws".
This means that it's segregated from regions in the various other
partitions.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
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>
