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>
The "certificate" argument in a provisioner connection block is only used
when using an SSH certificate authority, but because it uses the same
authorized_keys syntax that could be used to represent a public key on
the remote server it's perhaps tempting to think that it's necessary to
specify a plain public key here when attempting traditional keypair-based
authentication.
The configuration handling logic previously assumed incorrectly that the
result of parsing that string would always be *ssh.Certificate if parsing
succeeded at all, but the upstream library doesn't have a
certificate-specific parsing function and so we're using the more general
parser for the authorized_keys format and so the result could potentially
be of one of the many supported public key types, which would previously
have caused a type assertion panic.
Now we'll handle this as a normal error. The fact that communicators still
use error values directly rather than diagnostics means that we need to be
more terse than I would've liked to have been in this message, since the
reader of the message might not be an SSH authentication expert, but the
provisioner/communicator functionality long predates our modern idea of
diagnostics so I tried for a compromise here of mentioning that it's okay
to omit the certificate argument when you aren't trying to use a CA in the
hope that this is sufficient hint for someone who isn't yet aware of the
differences between these two different authentication methods.
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>
During the "refresh" and "plan" steps we build the marks for a managed
resource object's value as a combination of the marks from the input
(prior state or configuration, respectively) and the marks implied by the
provider schema.
However, the apply step was previously relying only on the marks from the
planned new state, without considering marks from the provider schema. That
meant that a sensitive attribute contained within a container that is
unknown during planning could not be marked as sensitive once the container
became known, because the corresponding value did not exist at all in the
planned new state and therefore could not carry a sensitive mark.
To fix this problem, this changes the apply step to match the strategy
already used in the refresh and plan steps: using combinePathValueMarks
to blend the dynamic marks with the static information from the schema,
so that the final value saved in the new state snapshot will have a full
set of sensitive markings for the next plan/apply round to rely on. Without
this the next plan/apply round would produce a spurious diff due to the
sensitivity of the nested attributes appearing to have changed.
This introduces a new test TestContext2Apply_sensitiveInsideUnknown which
covers the case where the sensitivity information comes from schema. The
preexisting test TestContext2Apply_additionalSensitiveFromState already
covered the case of dynamically-tracked sensitivity information, and
remains passing without modification after this change.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Over time the discussion about "lifecycle" blocks in the documentation
became confusing because the docs originally written for managed resource
lifecycle got partially generalized for resources of other modes and for
module calls, even though each of those has a completely different
lifecycle and thus a different set of lifecycle settings.
This is a first pass at trying to reorganize that so that the "lifecycle"
page is really just an index of all of the different kinds of lifecycle
block that exist in the language, while the main documentation for each
use of that block type now belongs with the documentation of the block
it's nested within.
While working on this I also found that there was some duplication inside
the "data sources" page where the same information was described multiple
times, and a few other cases where things had become inconsistent over
time. This also includes a little extra content to try to clarify the
difference between managed, data, and ephemeral resources and to make it
explicit that the "Resources" section is focused only on managed resources
because that is the primary resource mode.
As usual there's lots more that could be done here -- this documentation
has gradually evolved over time and is full of weird quirks due to that
evolution -- but I decided to draw a line here so that the diff wouldn't
get too large.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
As usual we've been gradually adding things to this in a decentralized and
uncoordinated fashion throughout the v1.11 development period, and so this
is a first pass of copyediting to try to present the information in a more
useful order (which is, of course, highly subjective), to describe the
changes in a more consistent writing style, to consolidate entries for
work that happened over multiple PRs but yet represents only one
end-user-facing feature, and to remove a few entries for changes that
are really just implementation details that don't affect the externally-
visible behavior of OpenTofu in any significant way.
We'll probably edit this some more throughout the v1.11 prerelease period,
but this is intended as a starting point for use with the v1.11.0-beta1
release.
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>
Implicit move statement for modules previously using `count` and
then moving to use `enabled`, or vice versa.
Signed-off-by: Diogenes Fernandes <diofeher@gmail.com>
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>
