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>
This is just a routine upgrade, which doesn't cause any significant changes
to OpenTofu's behavior.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This also upgrades two indirect dependencies, but we have those primarily
because of go-plugin and don't rely on them for any other significant
functionality.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Previously we were using a mixture of old and new, with our code generation
using the plugin from the old github.com/golang/protobuf library but
our callers using the modern google.golang.org/protobuf . We were also
using pretty ancient version of protoc.
This brings us up to the current latest releases and consistently using
the new Go protobuf library. There have been some notable changes to these
tools in the meantime:
Previously the protoc-gen-go plugin handled grpc by having its own
additional level of Go-specific "plugins" of which the gRPC codegen was
an example.
Now the protobuf generator and the gRPC generator are separate plugins
handled directly by protoc, which means the command line arguments are
a different shape and the gRPC stubs get generated in a separate file
from the main protobuf messages, rather than all being in one .pb.go file
as before.The results are otherwise similar, though.
The grpc codegen now also defaults to requiring that implementations embed
the generated "unimplemented" server, which is an implementation of each
service where the methods just immediately return the "unimplemented"
error. This is not super important for us because we maintain the generated
interfaces and their implementations together in the same repository
anyway, but adding the "unimplemented" server embeds was not a big change
and so seems better to follow the prevailing convention.
Using these new versions means that we could in principle now switch to
using protobuf edition 2024 and the new "sealed" style for Go code
generation, but this commit does not include any such changes and focuses
only on getting things upgraded with as few other changes as possible. We
can discuss using different codegen style later and deal with that in
separate commits.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is just a routine upgrade. Several of our other dependencies also
depend on these modules and so upgrading those others tends to ratchet up
these libraries. Therefore I'm upgrading them separately here really just
to allow subsequent upgrades of other dependencies without changing too
many dependencies at once in a single commit.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This upstream library (which I wrote, independently of my work on OpenTofu)
came about because "go-spew" tended to produce unreadable representations
of certain types commonly used in OpenTofu, whereas "go-dump" is really
just a pretty-printer for whatever a type might produce when formatted
using the %#v verb in package fmt.
Over time the uses of this seem to have decreased only to some leftover
situations where we wanted to pretty-print a cty.Value in a test, but
we already depend on go-cty-debug that has a more specialized
implementation of that behavior and so switching the few remaining callers
over to that allows us to remove one dependency.
(And, FWIW, that upstream dependency is effectively unmaintained; I don't
know of any callers of it other than OpenTofu itself, and after merging
this even OpenTofu won't depend on it anymore.)
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Previously, the source snippet was only showing the last defined
meta-argument. To have a better context of which meta-arguments
are being used, we start to show from the first one defined
until the last one.
Signed-off-by: Diogenes Fernandes <diofeher@gmail.com>
This uses the same auth package as the newly-rewritten Azure State
Backend, so many of the properties and environment variables are the
same. I have put this through both the compliance test as well as built
the binary and run some end-to-end tests, and found that it
appropriately uses the Azure key as expected.
Signed-off-by: Larry Bordowitz <laurence.bordowitz@gmail.com>
From some more practical testing of this I realized that usually the first
thing I want to know after seeing this warning is what the object literal
was being assigned to and what else was also defined inside it, and so
this sets the diagnostic's "context" to include the whole containing
object literal so that the source snippet in the diagnostic message is more
immediately useful, without having to cross-reference to the source code
in a separate text editor.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This generalizes the previously-added lint-like check for when an object
constructor is used to define an input variable and it contains a
definition for an attribute that isn't part of the target type, so that
now it also works for various nested structures that commonly arise in
real-world configurations.
Because this is now considerably more complicated I factored it out into
a new package called "lint" which could potentially grow to include other
similar "technically valid but probably a mistake" situations in future,
but for now it just introduced an opportunity to produce similar warning
messages for ignored attribute definitions in the default value for an
input variable.
It seems to me that there is actually no useful reason to include an
unexpected attribute definition in either of these two cases: that
attribute will never appear as part of any expression that any other part
of the configuration can use. Therefore I considered making these be
treated as errors rather than warnings, but turning something that was
previously valid into an error is risky so I'm suggesting that we start
with these as warnings and then consider upgrading them to errors in a
later release if we don't hear of anyone reporting a false-positive that
was _somehow_ actually useful. (I find that very unlikely, but still...)
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
We intentionally allow assigning object types with a superset of the
attributes included in an input variable's object type constraints because
it makes it possible to assign a whole object for which only some of the
attributes are relevant for one input variable but a different subset might
be relevant when the object value is used in a different part of the
configuration.
However, when the variable is defined using an object literal expression
there is no possible way an unexpected attribute could be useful in a
different part of the configuration, and so that's very very likely to be
a mistake rather than intentional. Therefore we'll generate a "linter-like"
warning in that case to help the author notice their mistake without
introducing any new "strict-mode" language features, or other complexity
that would be harder to maintain and evolve over time.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
As of go-getter v1.8.0, which we already upgraded in an earlier commit,
the S3 "getter" now uses the AWS SDK's default credentials chain
configuration and so follows the same set of credentials-searching
strategies that AWS CLI and other AWS SDK applications would follow.
We learned this only after having already merged that upgrade, so this is
a retroactive documentation and changelog update to describe the change.
Since go-getter is now delegating this whole question to the AWS SDK, our
future upgrades of the AWS SDK will automatically adopt any upstream
changes to the default credentials chain and so our documentation about
this is now more general than before: the intention is that our users can
generally assume that OpenTofu should support everything that is documented
as supported for the AWS CLI, instead of us listing out an explicit search
sequence that will be long and inevitably become outdated again.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
After adopting our original form of this policy we found out that GitHub's
security advisory feature will not allow us to publish "local-only"
advisories with no severity information, and instead sends copies of any
published advisory to other vulnerability databases. That is therefore not
a suitable way to handle false-positive reports, because distributing them
to other vulnerability databases would likely cause _even more_
false-positive reports from security scanners.
This therefore now describes the compromise we made in practice: we publish
our reasoning for classifying an advisory as false-positive in comments on
the relevant GitHub issue and then close that issue. This also mentions
our efforts to make these issues more discoverable by ensuring that the
advisory ID and affected module path are included in the summary of the
GitHub issue.
This is intended as a description of what we have already been doing in
practice, rather than as a proposal for a new policy.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
The original draft of this policy was written in future tense because we
had not begun following it yet. However, it makes more sense to write a
description of an active policy in present tense, so this retroactively
changes the existing sentences to make it clearer that this policy is
current rather than planned.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
The current OpenTofu language inherited a top-level block type named
"terraform" from its predecessor. Blocks of this type contain an
assortment of only-tangentially-related settings that seem to have ended
up there just because there wasn't any other obvious place to put them.
This document proposes new alternatives to those settings that are
intended to be tool-agnostic, while also making some room for other
changes we have already discussed including in future versions of the
language.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
