upstream/opentofu
1
0
Fork 0
mirror of https://github.com/opentofu/opentofu.git synced 2026-05-04 17:24:29 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions 3
opentofu/go.mod

338 lines
17 KiB
Modula-2
Raw Permalink Normal View History

Rename github.com/placeholderplaceholderplaceholder/opentf to github.com/opentofu/opentofu (#461)
2023-09-20 07:35:35 -04:00
module github.com/opentofu/opentofu
vendor: switch to Go modules govendor's lack of understanding of transitive versions was making it hell to figure out some dependency hell between etcd, grpc, and protobuf. After fighting with it for a few hours, I decided to give Go 1.11rc2 a try since previous experiments had been promising on the 1.11 tree in master. The dependencies all worked out first time when managed using the Go Modules code, and so we'll run with this now to continue to make progress though we may wish to back out of this nearer to release and return to govendor for a while until other projects have caught up. However, since this commit includes a vendor directory produced using Go Modules it doesn't actually _require_ Go 1.11 to build, and instead requires it only to make further changes to the selected versions in the vendor dir. Go 1.10's vendoring support will still find the modules in their expected locations within the vendor dir.
2018-08-24 19:13:05 -04:00
go.mod: Upgrade to Go 1.25.6 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>
2026-01-16 13:45:36 -05:00
go 1.25.6
go.mod: Use the new "tool" directive 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>
2025-10-09 14:01:32 -04:00
Disabling post-quantum key exchange mechanism X25519MLKEM768 (#2641) Signed-off-by: yottta <andrei.ciobanu@opentofu.org>
2025-03-28 07:01:33 -04:00
// At the time of adding this configuration, the new Go feature introduced here https://github.com/golang/go/issues/67061,
// was having a good amount of issues linked to, affecting AWS Firewall, GCP various services and a lot more.
// In go1.23 the godebug flag for this was named 'tlskyber', renamed in go1.24 to 'tlsmlkem'. https://tip.golang.org/doc/godebug#go-124
fix: `DirFromModule` related tests on Windows (#3289) Signed-off-by: Diogenes Fernandes <diofeher@gmail.com>
2025-09-20 14:51:29 -04:00
godebug (
tlsmlkem=0
winsymlink=0 // See https://github.com/opentofu/opentofu/pull/3289
)
Disabling post-quantum key exchange mechanism X25519MLKEM768 (#2641) Signed-off-by: yottta <andrei.ciobanu@opentofu.org>
2025-03-28 07:01:33 -04:00
vendor: switch to Go modules govendor's lack of understanding of transitive versions was making it hell to figure out some dependency hell between etcd, grpc, and protobuf. After fighting with it for a few hours, I decided to give Go 1.11rc2 a try since previous experiments had been promising on the 1.11 tree in master. The dependencies all worked out first time when managed using the Go Modules code, and so we'll run with this now to continue to make progress though we may wish to back out of this nearer to release and return to govendor for a while until other projects have caught up. However, since this commit includes a vendor directory produced using Go Modules it doesn't actually _require_ Go 1.11 to build, and instead requires it only to make further changes to the selected versions in the vendor dir. Go 1.10's vendoring support will still find the modules in their expected locations within the vendor dir.
2018-08-24 19:13:05 -04:00
require (
go.mod: go get cloud.google.com/go/kms@v1.23.2 && go get google.golang.org/api@v0.252.0 (#3410) Signed-off-by: Andrei Ciobanu <andrei.ciobanu@opentofu.org>
2025-10-22 08:28:42 -04:00
cloud.google.com/go/kms v1.23.2
go.mod: go get cloud.google.com/go/storage@v1.57.0 (#3385) Signed-off-by: Andrei Ciobanu <andrei.ciobanu@opentofu.org>
2025-10-17 11:16:53 -04:00
cloud.google.com/go/storage v1.57.0
go.mod: go get github.com/Azure/azure-sdk-for-go/sdk/azidentity@v1.13.1 (#3602) Signed-off-by: Andrei Ciobanu <andrei.ciobanu@opentofu.org>
2025-12-18 01:59:04 -05:00
github.com/Azure/azure-sdk-for-go/sdk/azcore v1.20.0
github.com/Azure/azure-sdk-for-go/sdk/azidentity v1.13.1
go.mod: Fix direct vs. indirect split 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>
2025-10-15 13:18:06 -04:00
github.com/Azure/azure-sdk-for-go/sdk/resourcemanager/resources/armresources v1.2.0
deps: upgrade Azure-related libraries Signed-off-by: Diogenes Fernandes <diofeher@gmail.com>
2025-10-21 10:09:03 -04:00
github.com/Azure/azure-sdk-for-go/sdk/resourcemanager/storage/armstorage v1.8.1
go.mod: Fix direct vs. indirect split 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>
2025-10-15 13:18:06 -04:00
github.com/Azure/azure-sdk-for-go/sdk/security/keyvault/azkeys v1.4.0
deps: upgrade Azure-related libraries Signed-off-by: Diogenes Fernandes <diofeher@gmail.com>
2025-10-21 10:09:03 -04:00
github.com/Azure/azure-sdk-for-go/sdk/storage/azblob v1.6.3
Bump github.com/Netflix/go-expect (#31103)
2022-05-31 11:24:01 -04:00
github.com/Netflix/go-expect v0.0.0-20220104043353-73e0943537d2
go.mod: go get github.com/ProtonMail/go-crypto@v1.3.0 This is a routine upgrade that does not cause any significant chance to OpenTofu's behavior. Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
2025-10-14 16:51:07 -04:00
github.com/ProtonMail/go-crypto v1.3.0
build(deps): bump github.com/agext/levenshtein from 1.2.2 to 1.2.3 Bumps [github.com/agext/levenshtein](https://github.com/agext/levenshtein) from 1.2.2 to 1.2.3. - [Release notes](https://github.com/agext/levenshtein/releases) - [Commits](https://github.com/agext/levenshtein/compare/v1.2.2...v1.2.3) --- updated-dependencies: - dependency-name: github.com/agext/levenshtein dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
2021-10-12 13:33:17 -04:00
github.com/agext/levenshtein v1.2.3
go.mod: go get github.com/aliyun/alibaba-cloud-sdk-go@v1.63.107 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>
2025-10-21 16:26:49 -04:00
github.com/aliyun/alibaba-cloud-sdk-go v1.63.107
github.com/aliyun/aliyun-oss-go-sdk v3.0.2+incompatible
github.com/aliyun/aliyun-tablestore-go-sdk v4.1.3+incompatible
upgrade go-cidr to v1.1.0
2020-07-08 10:57:57 -04:00
github.com/apparentlymart/go-cidr v1.1.0
command: Experimental "terraform test" command This is just a prototype to gather some feedback in our ongoing research on integration testing of Terraform modules. The hope is that by having a command integrated into Terraform itself it'll be easier for interested module authors to give it a try, and also easier for us to iterate quickly based on feedback without having to coordinate across multiple codebases. Everything about this is subject to change even in future patch releases. Since it's a CLI command rather than a configuration language feature it's not using the language experiments mechanism, but generates a warning similar to the one language experiments generate in order to be clear that backward compatibility is not guaranteed.
2021-02-08 19:03:15 -05:00
github.com/apparentlymart/go-shquot v0.0.1
vendor: upgrade go-userdirs library to fix openBSD crash (#26249) Fixes #26175
2020-09-15 14:14:25 -04:00
github.com/apparentlymart/go-userdirs v0.0.0-20200915174352-b0c018a67c13
go.mod: go get github.com/apparentlymart/go-versions@v1.0.3 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>
2025-10-09 12:50:29 -04:00
github.com/apparentlymart/go-versions v1.0.3
lang/eval: Beginnings of a different way to handle config eval 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>
2025-08-27 18:37:29 -04:00
github.com/apparentlymart/go-workgraph v0.0.0-20250609024419-b3453ef8d3e6
vendor: github.com/armon/circbuf@5111143e8da2 go get github.com/armon/circbuf@5111143e8da2 go mod tidy go mod vendor
2019-02-21 03:48:13 -05:00
github.com/armon/circbuf v0.0.0-20190214190532-5111143e8da2
go.mod: go get github.com/aws/aws-sdk-go-v2@v1.41.0 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>
2025-12-16 17:48:08 -05:00
github.com/aws/aws-sdk-go-v2 v1.41.0
go.mod: Upgrade our various AWS SDK for Go dependencies 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>
2025-10-10 14:31:50 -04:00
github.com/aws/aws-sdk-go-v2/feature/ec2/imds v1.18.9
github.com/aws/aws-sdk-go-v2/service/dynamodb v1.51.0
github.com/aws/aws-sdk-go-v2/service/kms v1.45.6
github.com/aws/aws-sdk-go-v2/service/s3 v1.88.4
go.mod: go get github.com/aws/aws-sdk-go-v2@v1.41.0 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>
2025-12-16 17:48:08 -05:00
github.com/aws/smithy-go v1.24.0
go.mod: go get github.com/bgentry/speakeasy@v0.2.0 This is mainly just to have one fewer dependency lagging behind latest, but includes a change to support running the "stty" program from any directory in PATH, rather than requiring it to be at /bin/stty, which improves portability to systems with non-traditional directory layouts, such as NixOS. Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
2025-08-25 13:23:23 -04:00
github.com/bgentry/speakeasy v0.2.0
go.mod: go get github.com/bmatcuk/doublestar/v4@v4.9.1 This is a routine dependency upgrade, but includes some behavior changes that fix some upstream bugs: - https://github.com/bmatcuk/doublestar/issues/96 - https://github.com/bmatcuk/doublestar/issues/88 Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
2025-10-06 16:21:16 -04:00
github.com/bmatcuk/doublestar/v4 v4.9.1
Add Solaris and AIX console support (#632) Signed-off-by: Mikel Olasagasti Uranga <mikel@olasagasti.info>
2024-01-03 12:32:31 -05:00
github.com/chzyer/readline v1.5.1
Use github.com/cli/browser (#602) Signed-off-by: Mikel Olasagasti Uranga <mikel@olasagasti.info>
2024-01-03 11:32:55 -05:00
github.com/cli/browser v1.3.0
Bump openbao/api to 2.3.0 in order to fix GO-2025-3783 (#3134) Signed-off-by: Andrei Ciobanu <andrei.ciobanu@opentofu.org>
2025-08-19 08:23:31 -04:00
github.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc
go get github.com/dylanmei/winrmtest
2022-03-01 16:52:48 -05:00
github.com/dylanmei/winrmtest v0.0.0-20210303004826-fbc9ae56efb6
[OpenTelemetry] Add traces to `init` command (#2665) Signed-off-by: James Humphries <james@james-humphries.co.uk> Signed-off-by: Christian Mesh <christianmesh1@gmail.com> Co-authored-by: Christian Mesh <christianmesh1@gmail.com>
2025-04-25 07:40:48 -04:00
github.com/go-logr/stdr v1.2.2
Upgrade github.com/go-viper/mapstructure/v2 to v2.4.0 (#3229) Signed-off-by: Christian Mesh <christianmesh1@gmail.com>
2025-09-04 08:20:04 -04:00
github.com/go-viper/mapstructure/v2 v2.4.0
[OpenTelemetry] Add traces to `init` command (#2665) Signed-off-by: James Humphries <james@james-humphries.co.uk> Signed-off-by: Christian Mesh <christianmesh1@gmail.com> Co-authored-by: Christian Mesh <christianmesh1@gmail.com>
2025-04-25 07:40:48 -04:00
github.com/google/go-cmp v0.7.0
Update to tfplugin proto 5.5 and 6.5 (#1435) Signed-off-by: Christian Mesh <christianmesh1@gmail.com>
2024-03-26 14:36:26 -04:00
github.com/google/uuid v1.6.0
go.mod: go get cloud.google.com/go/storage@v1.57.0 (#3385) Signed-off-by: Andrei Ciobanu <andrei.ciobanu@opentofu.org>
2025-10-17 11:16:53 -04:00
github.com/googleapis/gax-go/v2 v2.15.0
go.mod: Upgrade our various AWS SDK for Go dependencies 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>
2025-10-10 14:31:50 -04:00
github.com/hashicorp/aws-sdk-go-base/v2 v2.0.0-beta.67
go.mod: go get github.com/hashicorp/consul/api@v1.32.4 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>
2025-10-14 16:23:30 -04:00
github.com/hashicorp/consul/api v1.32.4
github.com/hashicorp/consul/sdk v0.16.3
dependencies: updating Azure Dependencies * github.com/Azure/azure-sdk-for-go to v47.1.0 * github.com/Azure/go-autorest to v0.11.10 * github.com/hashicorp/go-azure-helpers to v0.13.0 * github.com/tombuildsstuff/giovanni to v0.14.0
2020-10-27 14:06:17 -04:00
github.com/hashicorp/errwrap v1.1.0
Updates `github.com/hashicorp/aws-sdk-go-base` from 0.6.0 to 0.7.1
2021-08-19 13:44:48 -04:00
github.com/hashicorp/go-cleanhttp v0.5.2
go.mod: go get github.com/hashicorp/go-getter@v1.8.2 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>
2025-10-08 19:05:15 -04:00
github.com/hashicorp/go-getter v1.8.2
feat: init and get command support json format output (#1453) Signed-off-by: Syasusu <syasusu@163.com>
2024-04-02 12:32:37 -04:00
github.com/hashicorp/go-hclog v1.6.3
dependencies: upgrade all the azure things
2021-03-22 12:22:16 -04:00
github.com/hashicorp/go-multierror v1.1.1
go.mod: go get github.com/hashicorp/go-plugin@v1.7.0 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>
2025-10-08 18:31:56 -04:00
github.com/hashicorp/go-plugin v1.7.0
go.mod: go get github.com/hashicorp/go-retryablehttp@v0.7.8 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>
2025-10-09 12:56:00 -04:00
github.com/hashicorp/go-retryablehttp v0.7.8
go.mod: Update "go-tfe" library to latest release (#3413) Signed-off-by: Christian Mesh <christianmesh1@gmail.com>
2025-10-22 14:33:35 -04:00
github.com/hashicorp/go-tfe v1.95.0
Save detailed type outputs to JSONStateOutputs
2022-07-18 15:15:37 -04:00
github.com/hashicorp/go-uuid v1.0.3
go.mod: go get github.com/hashicorp/go-version@v1.8.0 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>
2025-12-09 18:27:47 -05:00
github.com/hashicorp/go-version v1.8.0
Bump openbao/api to 2.3.0 in order to fix GO-2025-3783 (#3134) Signed-off-by: Andrei Ciobanu <andrei.ciobanu@opentofu.org>
2025-08-19 08:23:31 -04:00
github.com/hashicorp/hcl v1.0.1-vault-5
Integrate provider functions (#1439) Signed-off-by: Christian Mesh <christianmesh1@gmail.com>
2024-04-10 08:04:08 -04:00
github.com/hashicorp/hcl/v2 v2.20.1
go.mod: go get github.com/hashicorp/jsonapi@v1.5.0 This is just a routine dependency upgrade. Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
2025-10-06 16:03:50 -04:00
github.com/hashicorp/jsonapi v1.5.0
deps: Bump github.com/aws/aws-sdk-go@v1.37.0 Changes: ``` * backend/s3: Support for AWS Single-Sign On (SSO) cached credentials ``` Updated via: ``` go get github.com/aws/aws-sdk-go@v1.37.0 go mod tidy ``` Please note that Terraform CLI will not initiate or perform the AWS SSO login flow. It is expected that you have already performed the SSO login flow using AWS CLI using the `aws sso login` command, or by some other mechanism before executing Terraform. More precisely, this credential handling must find a valid non-expired access token for the AWS SSO user portal URL in `~/.aws/sso/cache`. If a cached token is not found, is expired, or the file is malformed an error will be returned. You can use configure AWS SSO credentials from the AWS shared configuration file by specifying the required keys in the profile: ``` sso_account_id sso_region sso_role_name sso_start_url ``` For example, the following defines a profile "devsso" and specifies the AWS SSO parameters that defines the target account, role, sign-on portal, and the region where the user portal is located. Note: all SSO arguments must be provided, or an error will be returned. ``` [profile devsso] sso_start_url = https:my-sso-portal.awsapps.com/start sso_role_name = SSOReadOnlyRole sso_region = us-east-1 sso_account_id = 123456789012 ``` Additional Resources * [Configuring the AWS CLI to use AWS Single Sign-On](https:docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html) * [AWS Single Sign-On User Guide](https:docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)
2021-01-28 15:22:01 -05:00
github.com/jmespath/go-jmespath v0.4.0
vendor: github.com/kardianos/osext@2bc1f35cddc0
2019-02-22 17:16:33 -05:00
github.com/kardianos/osext v0.0.0-20190222173326-2bc1f35cddc0
go.mod: go get github.com/lib/pq@v1.10.9 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>
2025-10-14 18:43:35 -04:00
github.com/lib/pq v1.10.9
communicator/winrm: include configured timeout in winrm server * upgrade windows dependencies * communicator/winrm: include configured timeout in winrm server
2020-06-25 08:41:09 -04:00
github.com/masterzen/winrm v0.0.0-20200615185753-c42b5136ff88
Bump github.com/hashicorp/go-retryablehttp to fix CVE-2024-6104 (#1752) Signed-off-by: Mikel Olasagasti Uranga <mikel@olasagasti.info>
2024-07-02 06:58:14 -04:00
github.com/mattn/go-isatty v0.0.20
go.mod: go get github.com/mattn/go-shellwords@v1.0.12 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>
2025-10-09 14:32:17 -04:00
github.com/mattn/go-shellwords v1.0.12
go.mod: go get -u github.com/mitchellh/cli
2022-11-15 12:05:52 -05:00
github.com/mitchellh/cli v1.1.5
vendor: github.com/mitchellh/colorstring@d06e56a500db go get github.com/mitchellh/colorstring@d06e56a500db go mod tidy go mod vendor
2019-02-21 03:57:51 -05:00
github.com/mitchellh/colorstring v0.0.0-20190213212951-d06e56a500db
Bump github.com/mitchellh/copystructure from 1.0.0 to 1.2.0 Bumps [github.com/mitchellh/copystructure](https://github.com/mitchellh/copystructure) from 1.0.0 to 1.2.0. - [Release notes](https://github.com/mitchellh/copystructure/releases) - [Commits](https://github.com/mitchellh/copystructure/compare/v1.0.0...v1.2.0) --- updated-dependencies: - dependency-name: github.com/mitchellh/copystructure dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
2021-10-08 16:35:14 -04:00
github.com/mitchellh/copystructure v1.2.0
modules: update Azure deps to latest The dependencies here are dated and are causing conflicts with the ACME provider, namely the version of the top-level autorest package. This explicitly updates the Azure SDK and autorest packages, with the separately versioned sub-packages being added automatically.
2019-07-29 18:19:40 -04:00
github.com/mitchellh/go-homedir v1.1.0
vendor: github.com/mitchellh/go-linereader@1b945b3263eb go get github.com/mitchellh/go-linereader@1b945b3263eb go mod tidy go mod vendor
2019-02-21 03:59:37 -05:00
github.com/mitchellh/go-linereader v0.0.0-20190213213312-1b945b3263eb
go.mod: go get github.com/mitchellh/go-wordwrap@v1.0.1
2021-10-15 20:01:32 -04:00
github.com/mitchellh/go-wordwrap v1.0.1
Bump github.com/mitchellh/copystructure from 1.0.0 to 1.2.0 Bumps [github.com/mitchellh/copystructure](https://github.com/mitchellh/copystructure) from 1.0.0 to 1.2.0. - [Release notes](https://github.com/mitchellh/copystructure/releases) - [Commits](https://github.com/mitchellh/copystructure/compare/v1.0.0...v1.2.0) --- updated-dependencies: - dependency-name: github.com/mitchellh/copystructure dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
2021-10-08 16:35:14 -04:00
github.com/mitchellh/reflectwalk v1.0.2
go.mod: go get github.com/openbao/openbao/api/v2@v2.4.0 Signed-off-by: James Humphries <james@james-humphries.co.uk> Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
2025-09-04 08:21:19 -04:00
github.com/openbao/openbao/api/v2 v2.4.0
getproviders: PackageOCIBlobArchive for installing from OCI registries This is essentially a variation on PackageHTTPArchive that uses the OCI Distribution protocol to retrieve a package from an OCI repository, rather than directly from an HTTP URL. It uses a similar technique of first downloading the package to a temporary file and then delegating to the PackageLocalArchive location for the final extraction, but it additionally verifies that the given OCI blob descriptor seems reasonable and that the response matches the constraints given in that descriptor. Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
2025-03-07 19:37:07 -05:00
github.com/opencontainers/go-digest v1.0.0
go.mod: go get oras.land/oras-go/v2@v2.6.0 The new version has slightly changed the structure of returned error messages, so this includes some small compensating changes to avoid the messages redundantly mentioning the same tag or digest twice. Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
2025-08-22 15:14:23 -04:00
github.com/opencontainers/image-spec v1.1.1
Adopt OpenTofu's own "svchost" module Previously we were using a third-party library, but that doesn't have any support for passing context.Context through its API and so isn't suitable for our goals of adding OpenTelemetry tracing for all outgoing network requests. We now have our own fork that is updated to use context.Context. It also has a slightly reduced scope no longer including various details that are tightly-coupled to our cliconfig mechanism and so better placed in the main OpenTofu codebase so we can evolve it in future without making lockstep library releases. The "registry-address" library also uses svchost and uses some of its types in its public API, so this also incorporates v2 of that library that is updated to use our own svchost module. Unfortunately this commit is a mix of mechanical updates to the new libraries and some new code dealing with the functionality that is removed in our fork of svchost. The new code is primarily in the "svcauthconfig" package, which is similar in purpose "ociauthconfig" but for OpenTofu's own auth mechanism instead of the OCI Distribution protocol's auth mechanism. This includes some additional plumbing of context.Context where it was possible to do so without broad changes to files that would not otherwise have been included in this commit, but there are a few leftover spots that are context.TODO() which we'll address separately in later commits. This removes the temporary workaround from d079da6e9e55, since we are now able to plumb the OpenTelemetry span tree all the way to the service discovery requests. Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
2025-05-14 20:19:22 -04:00
github.com/opentofu/registry-address/v2 v2.0.0-20250611143131-d0a99bd8acdd
github.com/opentofu/svchost v0.0.0-20250610175836-86c9e5e3d8c8
communicator/winrm: include configured timeout in winrm server * upgrade windows dependencies * communicator/winrm: include configured timeout in winrm server
2020-06-25 08:41:09 -04:00
github.com/packer-community/winrmcp v0.0.0-20180921211025-c76d91c1e7db
deps: github.com/aws/aws-sdk-go@v1.30.12 [master] (#24745) * update github.com/aws/aws-sdk-go to v1.30.9 * deps: github.com/aws/aws-sdk-go@v1.30.12 Reference: https://github.com/hashicorp/terraform/issues/24710 Reference: https://github.com/hashicorp/terraform/issues/24741 Changes: ``` NOTES: * backend/s3: Region validation now automatically supports the new `af-south-1` (Africa (Cape Town)) region. For AWS operations to work in the new region, the region must be explicitly enabled as outlined in the [AWS Documentation](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html#rande-manage-enable). When the region is not enabled, the Terraform S3 Backend will return errors during credential validation (e.g. `error validating provider credentials: error calling sts:GetCallerIdentity: InvalidClientTokenId: The security token included in the request is invalid`). ENHANCEMENTS: * backend/s3: Support automatic region validation for `af-south-1` ``` Updated via: ```console $ go get github.com/aws/aws-sdk-go@v1.30.12 $ go mod tidy $ go mod vendor ``` Output from acceptance testing: ```console $ TF_ACC=1 go test -v ./backend/remote-state/s3 | grep '^--- ' --- PASS: TestBackend_impl (0.00s) --- PASS: TestBackendConfig (1.68s) --- PASS: TestBackendConfig_invalidKey (0.00s) --- PASS: TestBackendConfig_invalidSSECustomerKeyLength (0.00s) --- PASS: TestBackendConfig_invalidSSECustomerKeyEncoding (0.00s) --- PASS: TestBackendConfig_conflictingEncryptionSchema (0.00s) --- PASS: TestBackend (15.07s) --- PASS: TestBackendLocked (26.40s) --- PASS: TestBackendSSECustomerKey (16.99s) --- PASS: TestBackendExtraPaths (12.05s) --- PASS: TestBackendPrefixInWorkspace (5.55s) --- PASS: TestKeyEnv (45.07s) --- PASS: TestRemoteClient_impl (0.00s) --- PASS: TestRemoteClient (5.39s) --- PASS: TestRemoteClientLocks (14.30s) --- PASS: TestForceUnlock (20.08s) --- PASS: TestRemoteClient_clientMD5 (16.43s) --- PASS: TestRemoteClient_stateChecksum (24.58s) ``` Co-authored-by: Nicola Senno <nicola.senno@workday.com>
2020-04-24 12:20:04 -04:00
github.com/pkg/errors v0.9.1
Update the Consul API client Some users would want to use Consul namespaces when using the Consul backend but the version of the Consul API client we use is too old and don't support them. In preparation for this change this patch just update it the client and replace testutil.NewTestServerConfig() by testutil.NewTestServerConfigT() in the tests.
2021-07-14 08:42:45 -04:00
github.com/posener/complete v1.2.3
go.mod: go get github.com/spf13/afero@v1.15.0 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>
2025-10-09 19:45:48 -04:00
github.com/spf13/afero v1.15.0
go.mod: upgrade tencent libraries (#3412) Signed-off-by: Larry Bordowitz <laurence.bordowitz@gmail.com>
2025-10-22 11:51:52 -04:00
github.com/tencentcloud/tencentcloud-sdk-go/tencentcloud/common v1.1.41
github.com/tencentcloud/tencentcloud-sdk-go/tencentcloud/sts v1.1.11
github.com/tencentcloud/tencentcloud-sdk-go/tencentcloud/tag v1.1.0
github.com/tencentyun/cos-go-sdk-v5 v0.7.70
go.mod: go get github.com/xanzy/ssh-agent@v0.3.3 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>
2025-10-09 13:26:50 -04:00
github.com/xanzy/ssh-agent v0.3.3
go.mod: go get github.com/xlab/treeprint@v1.2.0 This is just a routine dependency upgrade. Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
2025-10-06 15:55:31 -04:00
github.com/xlab/treeprint v1.2.0
go.mod: go get github.com/zclconf/go-cty@v1.17.0 This release includes various performance improvents to the marks-related functionality, which is beneficial to OpenTofu because we've been making increasingly more use of marks for new use-cases lately. Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
2025-09-05 17:19:24 -04:00
github.com/zclconf/go-cty v1.17.0
Move varhcl (body variable inspection) into hcl fork (#1919) Signed-off-by: Christian Mesh <christianmesh1@gmail.com>
2024-08-23 10:01:07 -04:00
github.com/zclconf/go-cty-debug v0.0.0-20240509010212-0d6042c53940
go.mod: go get github.com/zclconf/go-cty-yaml@v1.2.0 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>
2025-12-17 19:31:18 -05:00
github.com/zclconf/go-cty-yaml v1.2.0
go.mod: go get go.opentelemetry.io/contrib/exporters/autoexport@v0.63.0 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>
2025-10-09 19:28:04 -04:00
go.opentelemetry.io/contrib/exporters/autoexport v0.63.0
go.mod: go get go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp@v0.63.0 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>
2025-10-14 12:32:06 -04:00
go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp v0.63.0
go.mod: go get go.opentelemetry.io/otel/sdk@v1.39.0 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>
2025-12-16 17:58:04 -05:00
go.opentelemetry.io/otel v1.39.0
go.opentelemetry.io/otel/sdk v1.39.0
go.opentelemetry.io/otel/trace v1.39.0
go.mod: go get go.uber.org/mock@v0.6.0 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>
2025-10-10 14:18:23 -04:00
go.uber.org/mock v0.6.0
go.mod: go get golang.org/x/net@v0.49.0 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>
2026-01-15 11:46:18 -05:00
golang.org/x/crypto v0.47.0
go.mod: Routine upgrades of golang.org/x/* modules 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>
2026-01-12 14:34:49 -05:00
golang.org/x/mod v0.32.0
go.mod: go get golang.org/x/net@v0.49.0 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>
2026-01-15 11:46:18 -05:00
golang.org/x/net v0.49.0
go.mod: Upgrade several golang.org/x/* dependencies 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>
2025-12-09 18:33:01 -05:00
golang.org/x/oauth2 v0.34.0
golang.org/x/sync v0.19.0
go.mod: Routine upgrades of golang.org/x/* modules 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>
2026-01-12 14:34:49 -05:00
golang.org/x/sys v0.40.0
golang.org/x/term v0.39.0
golang.org/x/text v0.33.0
go.mod: go get cloud.google.com/go/kms@v1.23.2 && go get google.golang.org/api@v0.252.0 (#3410) Signed-off-by: Andrei Ciobanu <andrei.ciobanu@opentofu.org>
2025-10-22 08:28:42 -04:00
google.golang.org/api v0.252.0
Use the latest protobuf tools and libraries throughout 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>
2025-10-06 20:25:14 -04:00
google.golang.org/grpc v1.76.0
google.golang.org/protobuf v1.36.10
go.mod: go get k8s.io/client-go@v0.34.1 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>
2025-10-20 12:11:20 -04:00
k8s.io/api v0.34.1
k8s.io/apimachinery v0.34.1
k8s.io/client-go v0.34.1
k8s.io/utils v0.0.0-20251002143259-bc988d571ff4
go.mod: go get oras.land/oras-go/v2@v2.6.0 The new version has slightly changed the structure of returned error messages, so this includes some small compensating changes to avoid the messages redundantly mentioning the same tag or digest twice. Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
2025-08-22 15:14:23 -04:00
oras.land/oras-go/v2 v2.6.0
update the go.mod format for go1.17.2
2021-10-08 15:54:13 -04:00
)
require (
go.mod: go get cloud.google.com/go/storage@v1.57.0 (#3385) Signed-off-by: Andrei Ciobanu <andrei.ciobanu@opentofu.org>
2025-10-17 11:16:53 -04:00
cel.dev/expr v0.24.0 // indirect
cloud.google.com/go v0.121.6 // indirect
go.mod: go get cloud.google.com/go/kms@v1.23.2 && go get google.golang.org/api@v0.252.0 (#3410) Signed-off-by: Andrei Ciobanu <andrei.ciobanu@opentofu.org>
2025-10-22 08:28:42 -04:00
cloud.google.com/go/auth v0.17.0 // indirect
go.mod: go get cloud.google.com/go/storage@v1.57.0 (#3385) Signed-off-by: Andrei Ciobanu <andrei.ciobanu@opentofu.org>
2025-10-17 11:16:53 -04:00
cloud.google.com/go/auth/oauth2adapt v0.2.8 // indirect
go.mod: go get cloud.google.com/go/kms@v1.23.2 && go get google.golang.org/api@v0.252.0 (#3410) Signed-off-by: Andrei Ciobanu <andrei.ciobanu@opentofu.org>
2025-10-22 08:28:42 -04:00
cloud.google.com/go/compute/metadata v0.9.0 // indirect
go.mod: go get cloud.google.com/go/storage@v1.57.0 (#3385) Signed-off-by: Andrei Ciobanu <andrei.ciobanu@opentofu.org>
2025-10-17 11:16:53 -04:00
cloud.google.com/go/iam v1.5.2 // indirect
cloud.google.com/go/longrunning v0.6.7 // indirect
cloud.google.com/go/monitoring v1.24.2 // indirect
build: Generate copyright headers automatically HashiCorp legal now requires a copyright claim in a comment at the top of every substantial file in this repository. If we don't add this ourselves then a bot will open a PR to add missing entries, but that process adds git history, pull request, and GitHub notification noise so instead we'll deal with it proactively as part of our usual code generation steps. This means that pull requests will fail their checks if there are any files that lack copyright headers, so we can deal with those before we merge rather than in a subsequent PR.
2023-05-08 19:02:22 -04:00
github.com/AlecAivazis/survey/v2 v2.3.6 // indirect
go.mod: Use the new "tool" directive 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>
2025-10-09 14:01:32 -04:00
github.com/Azure/azure-sdk-for-go/sdk/internal v1.11.2 // indirect
github.com/Azure/azure-sdk-for-go/sdk/security/keyvault/internal v1.2.0 // indirect
update the go.mod format for go1.17.2
2021-10-08 15:54:13 -04:00
github.com/Azure/go-ntlmssp v0.0.0-20200615164410-66371956d46c // indirect
go.mod: go get github.com/Azure/azure-sdk-for-go/sdk/azidentity@v1.13.1 (#3602) Signed-off-by: Andrei Ciobanu <andrei.ciobanu@opentofu.org>
2025-12-18 01:59:04 -05:00
github.com/AzureAD/microsoft-authentication-library-for-go v1.6.0 // indirect
build: Use Go 1.20.0 This changes which Go version we use for official releases and for everyday development and testing. At the time of this commit Go 1.20.1 is available but is not yet included in goenv, the tool that we use in some environments for reacting automatically to this file. I expect we'll upgrade to Go 1.20.1 very soon, but this is a routine upgrade to the latest major release so that we can start soaking in the new compiler and library behaviors throughout the v1.5 development period. Go 1.20 continues to support only Unicode 13, so we do not need to make any changes to our supporting packages that also rely on Unicode data.
2023-02-14 20:48:43 -05:00
github.com/BurntSushi/toml v1.2.1 // indirect
update the go.mod format for go1.17.2
2021-10-08 15:54:13 -04:00
github.com/ChrisTrenkamp/goxpath v0.0.0-20190607011252-c5096ec8773d // indirect
go.mod: go get cloud.google.com/go/storage@v1.57.0 (#3385) Signed-off-by: Andrei Ciobanu <andrei.ciobanu@opentofu.org>
2025-10-17 11:16:53 -04:00
github.com/GoogleCloudPlatform/opentelemetry-operations-go/detectors/gcp v1.29.0 // indirect
github.com/GoogleCloudPlatform/opentelemetry-operations-go/exporter/metric v0.53.0 // indirect
github.com/GoogleCloudPlatform/opentelemetry-operations-go/internal/resourcemapping v0.53.0 // indirect
go.mod: go get -u github.com/mitchellh/cli
2022-11-15 12:05:52 -05:00
github.com/Masterminds/goutils v1.1.1 // indirect
bump mitchellh/cli from 1.1.2 to 1.1.3 (#30914)
2022-04-25 07:06:12 -04:00
github.com/Masterminds/semver/v3 v3.1.1 // indirect
go.mod: go get -u github.com/mitchellh/cli
2022-11-15 12:05:52 -05:00
github.com/Masterminds/sprig/v3 v3.2.2 // indirect
go.mod: go get cloud.google.com/go/storage@v1.57.0 (#3385) Signed-off-by: Andrei Ciobanu <andrei.ciobanu@opentofu.org>
2025-10-17 11:16:53 -04:00
github.com/Microsoft/go-winio v0.6.2 // indirect
go get github.com/dylanmei/winrmtest
2022-03-01 16:52:48 -05:00
github.com/antchfx/xmlquery v1.3.5 // indirect
github.com/antchfx/xpath v1.1.10 // indirect
Bump versions for hashicorp/hcl hashicorp/go-getter zclconf/go-cty (#717)
2023-10-13 11:05:20 -04:00
github.com/apparentlymart/go-textseg/v15 v15.0.0 // indirect
go.mod: go get github.com/hashicorp/consul/api@v1.32.4 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>
2025-10-14 16:23:30 -04:00
github.com/armon/go-metrics v0.4.1 // indirect
update the go.mod format for go1.17.2
2021-10-08 15:54:13 -04:00
github.com/armon/go-radix v1.0.0 // indirect
build: Generate copyright headers automatically HashiCorp legal now requires a copyright claim in a comment at the top of every substantial file in this repository. If we don't add this ourselves then a bot will open a PR to add missing entries, but that process adds git history, pull request, and GitHub notification noise so instead we'll deal with it proactively as part of our usual code generation steps. This means that pull requests will fail their checks if there are any files that lack copyright headers, so we can deal with those before we merge rather than in a subsequent PR.
2023-05-08 19:02:22 -04:00
github.com/asaskevich/govalidator v0.0.0-20200907205600-7a23bdc65eef // indirect
go.mod: Upgrade our various AWS SDK for Go dependencies 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>
2025-10-10 14:31:50 -04:00
github.com/aws/aws-sdk-go-v2/aws/protocol/eventstream v1.7.1 // indirect
github.com/aws/aws-sdk-go-v2/config v1.31.12 // indirect
github.com/aws/aws-sdk-go-v2/credentials v1.18.16 // indirect
github.com/aws/aws-sdk-go-v2/internal/configsources v1.4.9 // indirect
github.com/aws/aws-sdk-go-v2/internal/endpoints/v2 v2.7.9 // indirect
go.mod: go get github.com/hashicorp/go-getter@v1.8.0 This is the first version of go-getter that uses AWS SDK for Go v2, instead of the now-obsolete SDK v1. This means that we no longer have an indirect dependency on the obsolete SDK version, and so should generate less noise for security scanners that are configured to check for unmaintained dependencies. This does unfortunately also force upgrading some of the AWS SDK v2 dependencies, which potentially affects the "s3" backend too. This is the typical risk of having all of these external integrations linked directly into our executables, but most of these are just minor upgrades that we likely would've adopted in the near future anyway. The newer version of go-getter also uses newer versions of some of its other dependencies, but we were already on newer versions of most of them anyway and so the main effect here is just to drop the older versions from our go.sum file now that they are no longer included in the module version selection process. Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
2025-09-15 12:02:01 -04:00
github.com/aws/aws-sdk-go-v2/internal/ini v1.8.3 // indirect
go.mod: Upgrade our various AWS SDK for Go dependencies 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>
2025-10-10 14:31:50 -04:00
github.com/aws/aws-sdk-go-v2/internal/v4a v1.4.9 // indirect
github.com/aws/aws-sdk-go-v2/service/iam v1.47.7 // indirect
github.com/aws/aws-sdk-go-v2/service/internal/accept-encoding v1.13.1 // indirect
github.com/aws/aws-sdk-go-v2/service/internal/checksum v1.9.0 // indirect
github.com/aws/aws-sdk-go-v2/service/internal/endpoint-discovery v1.11.9 // indirect
github.com/aws/aws-sdk-go-v2/service/internal/presigned-url v1.13.9 // indirect
github.com/aws/aws-sdk-go-v2/service/internal/s3shared v1.19.9 // indirect
github.com/aws/aws-sdk-go-v2/service/sns v1.38.5 // indirect
github.com/aws/aws-sdk-go-v2/service/sqs v1.42.8 // indirect
github.com/aws/aws-sdk-go-v2/service/sso v1.29.6 // indirect
github.com/aws/aws-sdk-go-v2/service/ssooidc v1.35.1 // indirect
github.com/aws/aws-sdk-go-v2/service/sts v1.38.6 // indirect
go.mod: go get go.opentelemetry.io/contrib/exporters/autoexport@v0.63.0 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>
2025-10-09 19:28:04 -04:00
github.com/beorn7/perks v1.0.1 // indirect
update the go.mod format for go1.17.2
2021-10-08 15:54:13 -04:00
github.com/bgentry/go-netrc v0.0.0-20140422174119-9fd32a8b3d3d // indirect
build: Generate copyright headers automatically HashiCorp legal now requires a copyright claim in a comment at the top of every substantial file in this repository. If we don't add this ourselves then a bot will open a PR to add missing entries, but that process adds git history, pull request, and GitHub notification noise so instead we'll deal with it proactively as part of our usual code generation steps. This means that pull requests will fail their checks if there are any files that lack copyright headers, so we can deal with those before we merge rather than in a subsequent PR.
2023-05-08 19:02:22 -04:00
github.com/bradleyfalzon/ghinstallation/v2 v2.1.0 // indirect
Remove experimental marker from OpenBao transit (#2536) Signed-off-by: Alexander Scheel <alexander.m.scheel@gmail.com>
2025-02-21 10:00:13 -05:00
github.com/cenkalti/backoff/v4 v4.3.0 // indirect
go.mod: go get go.opentelemetry.io/contrib/exporters/autoexport@v0.63.0 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>
2025-10-09 19:28:04 -04:00
github.com/cenkalti/backoff/v5 v5.0.3 // indirect
github.com/cespare/xxhash/v2 v2.3.0 // indirect
go.mod: upgrade tencent libraries (#3412) Signed-off-by: Larry Bordowitz <laurence.bordowitz@gmail.com>
2025-10-22 11:51:52 -04:00
github.com/clbanning/mxj v1.8.4 // indirect
build: Generate copyright headers automatically HashiCorp legal now requires a copyright claim in a comment at the top of every substantial file in this repository. If we don't add this ourselves then a bot will open a PR to add missing entries, but that process adds git history, pull request, and GitHub notification noise so instead we'll deal with it proactively as part of our usual code generation steps. This means that pull requests will fail their checks if there are any files that lack copyright headers, so we can deal with those before we merge rather than in a subsequent PR.
2023-05-08 19:02:22 -04:00
github.com/cli/go-gh v1.0.0 // indirect
github.com/cli/safeexec v1.0.0 // indirect
github.com/cli/shurcooL-graphql v0.0.2 // indirect
go.mod: go get github.com/cloudflare/circl@v1.6.1 This release contains fixes for a security advisory that does not affect OpenTofu. Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
2025-06-16 13:48:35 -04:00
github.com/cloudflare/circl v1.6.1 // indirect
go.mod: go get cloud.google.com/go/storage@v1.57.0 (#3385) Signed-off-by: Andrei Ciobanu <andrei.ciobanu@opentofu.org>
2025-10-17 11:16:53 -04:00
github.com/cncf/xds/go v0.0.0-20250501225837-2ac532fd4443 // indirect
Bump github.com/Netflix/go-expect (#31103)
2022-05-31 11:24:01 -04:00
github.com/creack/pty v1.1.18 // indirect
update the go.mod format for go1.17.2
2021-10-08 15:54:13 -04:00
github.com/dylanmei/iso8601 v0.1.0 // indirect
go.mod: go get k8s.io/client-go@v0.34.1 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>
2025-10-20 12:11:20 -04:00
github.com/emicklei/go-restful/v3 v3.12.2 // indirect
go.mod: go get cloud.google.com/go/storage@v1.57.0 (#3385) Signed-off-by: Andrei Ciobanu <andrei.ciobanu@opentofu.org>
2025-10-17 11:16:53 -04:00
github.com/envoyproxy/go-control-plane/envoy v1.32.4 // indirect
github.com/envoyproxy/protoc-gen-validate v1.2.1 // indirect
Upgrade aws sdk to a version that will give us access to s3 conditional writes arguments (#2528) Signed-off-by: yottta <andrei.ciobanu@opentofu.org>
2025-02-18 08:58:17 -05:00
github.com/fatih/color v1.18.0 // indirect
Update to tfplugin proto 5.5 and 6.5 (#1435) Signed-off-by: Christian Mesh <christianmesh1@gmail.com>
2024-03-26 14:36:26 -04:00
github.com/felixge/httpsnoop v1.0.4 // indirect
build: Generate copyright headers automatically HashiCorp legal now requires a copyright claim in a comment at the top of every substantial file in this repository. If we don't add this ourselves then a bot will open a PR to add missing entries, but that process adds git history, pull request, and GitHub notification noise so instead we'll deal with it proactively as part of our usual code generation steps. This means that pull requests will fail their checks if there are any files that lack copyright headers, so we can deal with those before we merge rather than in a subsequent PR.
2023-05-08 19:02:22 -04:00
github.com/fsnotify/fsnotify v1.5.4 // indirect
go.mod: go get k8s.io/client-go@v0.34.1 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>
2025-10-20 12:11:20 -04:00
github.com/fxamacker/cbor/v2 v2.9.0 // indirect
go.mod: go get github.com/openbao/openbao/api/v2@v2.4.0 Signed-off-by: James Humphries <james@james-humphries.co.uk> Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
2025-09-04 08:21:19 -04:00
github.com/go-jose/go-jose/v4 v4.1.2 // indirect
go.mod: Update OpenTelemetry dependencies to v1.38.0 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>
2025-10-06 20:33:13 -04:00
github.com/go-logr/logr v1.4.3 // indirect
build: Generate copyright headers automatically HashiCorp legal now requires a copyright claim in a comment at the top of every substantial file in this repository. If we don't add this ourselves then a bot will open a PR to add missing entries, but that process adds git history, pull request, and GitHub notification noise so instead we'll deal with it proactively as part of our usual code generation steps. This means that pull requests will fail their checks if there are any files that lack copyright headers, so we can deal with those before we merge rather than in a subsequent PR.
2023-05-08 19:02:22 -04:00
github.com/go-openapi/errors v0.20.2 // indirect
go.mod: go get k8s.io/client-go@v0.34.1 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>
2025-10-20 12:11:20 -04:00
github.com/go-openapi/jsonpointer v0.21.0 // indirect
github.com/go-openapi/jsonreference v0.20.2 // indirect
build: Generate copyright headers automatically HashiCorp legal now requires a copyright claim in a comment at the top of every substantial file in this repository. If we don't add this ourselves then a bot will open a PR to add missing entries, but that process adds git history, pull request, and GitHub notification noise so instead we'll deal with it proactively as part of our usual code generation steps. This means that pull requests will fail their checks if there are any files that lack copyright headers, so we can deal with those before we merge rather than in a subsequent PR.
2023-05-08 19:02:22 -04:00
github.com/go-openapi/strfmt v0.21.3 // indirect
go.mod: go get k8s.io/client-go@v0.34.1 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>
2025-10-20 12:11:20 -04:00
github.com/go-openapi/swag v0.23.0 // indirect
go get github.com/dylanmei/winrmtest
2022-03-01 16:52:48 -05:00
github.com/gofrs/uuid v4.0.0+incompatible // indirect
update k8s packages from retracted module Use the latest k8s.io packages from v0.21
2021-11-16 14:42:06 -05:00
github.com/gogo/protobuf v1.3.2 // indirect
Fix CVE-2025-30204 (#2627) Signed-off-by: yottta <andrei.ciobanu@opentofu.org>
2025-03-25 04:27:11 -04:00
github.com/golang-jwt/jwt/v4 v4.5.2 // indirect
deps: upgrade Azure-related libraries Signed-off-by: Diogenes Fernandes <diofeher@gmail.com>
2025-10-21 10:09:03 -04:00
github.com/golang-jwt/jwt/v5 v5.3.0 // indirect
Updated for latest go-tfe run task changes
2022-02-25 15:32:16 -05:00
github.com/golang/groupcache v0.0.0-20210331224755-41bb18bfe9da // indirect
go.mod: go get google.golang.org/grpc@v1.73.0 This is not the latest available version of this module currently available, but it's the newest version we can reach without ratcheting upgrades for other dependencies that are riskier because of their use by the state storage backend implementations. We'll update this further later once we've dealt with those other upgrades, but still worth upgrading grpc as far as possible given that it's a network protocol implementation and therefore more sensitive to security advisories that tend to be harder to deal with the further behind we get. This does unfortunately still upgrade a small number of indirect dependencies, but the protobuf packages are not ones we use directly (since we now use the newer google.golang.org/protobuf primarily), and cloud.google.com/go/compute/metadata is used tangentially by the "gcs" backend when OpenTofu is running on a Google Compute Engine instance, so the risk of all of these is relatively small. Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
2025-08-27 16:25:42 -04:00
github.com/golang/protobuf v1.5.4 // indirect
go.mod: go get k8s.io/client-go@v0.34.1 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>
2025-10-20 12:11:20 -04:00
github.com/google/gnostic-models v0.7.0 // indirect
build: Generate copyright headers automatically HashiCorp legal now requires a copyright claim in a comment at the top of every substantial file in this repository. If we don't add this ourselves then a bot will open a PR to add missing entries, but that process adds git history, pull request, and GitHub notification noise so instead we'll deal with it proactively as part of our usual code generation steps. This means that pull requests will fail their checks if there are any files that lack copyright headers, so we can deal with those before we merge rather than in a subsequent PR.
2023-05-08 19:02:22 -04:00
github.com/google/go-github/v45 v45.2.0 // indirect
update the go.mod format for go1.17.2
2021-10-08 15:54:13 -04:00
github.com/google/go-querystring v1.1.0 // indirect
go.mod: go get cloud.google.com/go/storage@v1.57.0 (#3385) Signed-off-by: Andrei Ciobanu <andrei.ciobanu@opentofu.org>
2025-10-17 11:16:53 -04:00
github.com/google/s2a-go v0.1.9 // indirect
github.com/googleapis/enterprise-certificate-proxy v0.3.6 // indirect
go.mod: go get go.opentelemetry.io/contrib/exporters/autoexport@v0.63.0 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>
2025-10-09 19:28:04 -04:00
github.com/grafana/regexp v0.0.0-20240518133315-a468a5bfb3bc // indirect
github.com/grpc-ecosystem/grpc-gateway/v2 v2.27.2 // indirect
go.mod: Use the new "tool" directive 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>
2025-10-09 14:01:32 -04:00
github.com/hashicorp/copywrite v0.16.3 // indirect
go.mod: go get github.com/hashicorp/consul/api@v1.32.4 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>
2025-10-14 16:23:30 -04:00
github.com/hashicorp/go-immutable-radix v1.3.1 // indirect
update the go.mod format for go1.17.2
2021-10-08 15:54:13 -04:00
github.com/hashicorp/go-rootcerts v1.0.2 // indirect
Bump openbao/api to 2.3.0 in order to fix GO-2025-3783 (#3134) Signed-off-by: Andrei Ciobanu <andrei.ciobanu@opentofu.org>
2025-08-19 08:23:31 -04:00
github.com/hashicorp/go-secure-stdlib/parseutil v0.2.0 // indirect
add OpenBao as key provider for state encryption (#1436) Signed-off-by: ollevche <ollevche@gmail.com>
2024-04-08 08:38:17 -04:00
github.com/hashicorp/go-secure-stdlib/strutil v0.1.2 // indirect
go.mod: Update "go-tfe" library to latest release (#3413) Signed-off-by: Christian Mesh <christianmesh1@gmail.com>
2025-10-22 14:33:35 -04:00
github.com/hashicorp/go-slug v0.16.8 // indirect
Bump openbao/api to 2.3.0 in order to fix GO-2025-3783 (#3134) Signed-off-by: Andrei Ciobanu <andrei.ciobanu@opentofu.org>
2025-08-19 08:23:31 -04:00
github.com/hashicorp/go-sockaddr v1.0.7 // indirect
go.mod: go get github.com/hashicorp/consul/api@v1.32.4 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>
2025-10-14 16:23:30 -04:00
github.com/hashicorp/golang-lru v0.5.4 // indirect
github.com/hashicorp/serf v0.10.1 // indirect
Upgrade AWS SDK (#701) Signed-off-by: Elbaz <eranelbaz97+github@gmail.com> Signed-off-by: tomasmik <tomasmik@protonmail.com> Co-authored-by: tomasmik <tomasmik@protonmail.com>
2023-10-19 08:00:36 -04:00
github.com/hashicorp/terraform-plugin-log v0.9.0 // indirect
go.mod: go get github.com/hashicorp/go-plugin@v1.7.0 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>
2025-10-08 18:31:56 -04:00
github.com/hashicorp/yamux v0.1.2 // indirect
build: Generate copyright headers automatically HashiCorp legal now requires a copyright claim in a comment at the top of every substantial file in this repository. If we don't add this ourselves then a bot will open a PR to add missing entries, but that process adds git history, pull request, and GitHub notification noise so instead we'll deal with it proactively as part of our usual code generation steps. This means that pull requests will fail their checks if there are any files that lack copyright headers, so we can deal with those before we merge rather than in a subsequent PR.
2023-05-08 19:02:22 -04:00
github.com/henvic/httpretty v0.0.6 // indirect
go.mod: go get -u github.com/mitchellh/cli
2022-11-15 12:05:52 -05:00
github.com/huandu/xstrings v1.3.3 // indirect
github.com/imdario/mergo v0.3.13 // indirect
build: Generate copyright headers automatically HashiCorp legal now requires a copyright claim in a comment at the top of every substantial file in this repository. If we don't add this ourselves then a bot will open a PR to add missing entries, but that process adds git history, pull request, and GitHub notification noise so instead we'll deal with it proactively as part of our usual code generation steps. This means that pull requests will fail their checks if there are any files that lack copyright headers, so we can deal with those before we merge rather than in a subsequent PR.
2023-05-08 19:02:22 -04:00
github.com/inconshreveable/mousetrap v1.0.1 // indirect
github.com/jedib0t/go-pretty v4.3.0+incompatible // indirect
github.com/jedib0t/go-pretty/v6 v6.4.4 // indirect
github.com/joho/godotenv v1.3.0 // indirect
go.mod: go get k8s.io/client-go@v0.34.1 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>
2025-10-20 12:11:20 -04:00
github.com/josharian/intern v1.0.0 // indirect
Updated for latest go-tfe run task changes
2022-02-25 15:32:16 -05:00
github.com/json-iterator/go v1.1.12 // indirect
build: Generate copyright headers automatically HashiCorp legal now requires a copyright claim in a comment at the top of every substantial file in this repository. If we don't add this ourselves then a bot will open a PR to add missing entries, but that process adds git history, pull request, and GitHub notification noise so instead we'll deal with it proactively as part of our usual code generation steps. This means that pull requests will fail their checks if there are any files that lack copyright headers, so we can deal with those before we merge rather than in a subsequent PR.
2023-05-08 19:02:22 -04:00
github.com/kballard/go-shellquote v0.0.0-20180428030007-95032a82bc51 // indirect
go.mod: go get go.opentelemetry.io/contrib/exporters/autoexport@v0.63.0 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>
2025-10-09 19:28:04 -04:00
github.com/klauspost/compress v1.18.0 // indirect
build: Generate copyright headers automatically HashiCorp legal now requires a copyright claim in a comment at the top of every substantial file in this repository. If we don't add this ourselves then a bot will open a PR to add missing entries, but that process adds git history, pull request, and GitHub notification noise so instead we'll deal with it proactively as part of our usual code generation steps. This means that pull requests will fail their checks if there are any files that lack copyright headers, so we can deal with those before we merge rather than in a subsequent PR.
2023-05-08 19:02:22 -04:00
github.com/knadh/koanf v1.5.0 // indirect
go.mod: Use the new "tool" directive 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>
2025-10-09 14:01:32 -04:00
github.com/kylelemons/godebug v1.1.0 // indirect
build: Generate copyright headers automatically HashiCorp legal now requires a copyright claim in a comment at the top of every substantial file in this repository. If we don't add this ourselves then a bot will open a PR to add missing entries, but that process adds git history, pull request, and GitHub notification noise so instead we'll deal with it proactively as part of our usual code generation steps. This means that pull requests will fail their checks if there are any files that lack copyright headers, so we can deal with those before we merge rather than in a subsequent PR.
2023-05-08 19:02:22 -04:00
github.com/lucasb-eyer/go-colorful v1.2.0 // indirect
go.mod: go get k8s.io/client-go@v0.34.1 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>
2025-10-20 12:11:20 -04:00
github.com/mailru/easyjson v0.7.7 // indirect
update the go.mod format for go1.17.2
2021-10-08 15:54:13 -04:00
github.com/masterzen/simplexml v0.0.0-20190410153822-31eea3082786 // indirect
Bump openbao/api to 2.3.0 in order to fix GO-2025-3783 (#3134) Signed-off-by: Andrei Ciobanu <andrei.ciobanu@opentofu.org>
2025-08-19 08:23:31 -04:00
github.com/mattn/go-colorable v0.1.14 // indirect
build: Generate copyright headers automatically HashiCorp legal now requires a copyright claim in a comment at the top of every substantial file in this repository. If we don't add this ourselves then a bot will open a PR to add missing entries, but that process adds git history, pull request, and GitHub notification noise so instead we'll deal with it proactively as part of our usual code generation steps. This means that pull requests will fail their checks if there are any files that lack copyright headers, so we can deal with those before we merge rather than in a subsequent PR.
2023-05-08 19:02:22 -04:00
github.com/mattn/go-runewidth v0.0.13 // indirect
github.com/mergestat/timediff v0.0.3 // indirect
github.com/mgutz/ansi v0.0.0-20200706080929-d51e80ef957d // indirect
go.mod: Use the new "tool" directive 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>
2025-10-09 14:01:32 -04:00
github.com/mitchellh/gox v1.0.1 // indirect
update the go.mod format for go1.17.2
2021-10-08 15:54:13 -04:00
github.com/mitchellh/iochan v1.0.0 // indirect
Switch from mitchellh/mapstructure to go-viper/mapstructure/v2 (#1330) Signed-off-by: Mikel Olasagasti Uranga <mikel@olasagasti.info>
2024-03-06 07:26:22 -05:00
github.com/mitchellh/mapstructure v1.5.0 // indirect
update the go.mod format for go1.17.2
2021-10-08 15:54:13 -04:00
github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd // indirect
go.mod: go get k8s.io/client-go@v0.34.1 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>
2025-10-20 12:11:20 -04:00
github.com/modern-go/reflect2 v1.0.3-0.20250322232337-35a7c28c31ee // indirect
update the go.mod format for go1.17.2
2021-10-08 15:54:13 -04:00
github.com/mozillazg/go-httpheader v0.3.0 // indirect
build: Generate copyright headers automatically HashiCorp legal now requires a copyright claim in a comment at the top of every substantial file in this repository. If we don't add this ourselves then a bot will open a PR to add missing entries, but that process adds git history, pull request, and GitHub notification noise so instead we'll deal with it proactively as part of our usual code generation steps. This means that pull requests will fail their checks if there are any files that lack copyright headers, so we can deal with those before we merge rather than in a subsequent PR.
2023-05-08 19:02:22 -04:00
github.com/muesli/termenv v0.12.0 // indirect
go.mod: go get go.opentelemetry.io/contrib/exporters/autoexport@v0.63.0 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>
2025-10-09 19:28:04 -04:00
github.com/munnerz/goautoneg v0.0.0-20191010083416-a7dc8b61c822 // indirect
update the go.mod format for go1.17.2
2021-10-08 15:54:13 -04:00
github.com/nu7hatch/gouuid v0.0.0-20131221200532-179d4d0c4d8d // indirect
go.mod: go get github.com/hashicorp/go-plugin@v1.7.0 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>
2025-10-08 18:31:56 -04:00
github.com/oklog/run v1.1.0 // indirect
build: Generate copyright headers automatically HashiCorp legal now requires a copyright claim in a comment at the top of every substantial file in this repository. If we don't add this ourselves then a bot will open a PR to add missing entries, but that process adds git history, pull request, and GitHub notification noise so instead we'll deal with it proactively as part of our usual code generation steps. This means that pull requests will fail their checks if there are any files that lack copyright headers, so we can deal with those before we merge rather than in a subsequent PR.
2023-05-08 19:02:22 -04:00
github.com/oklog/ulid v1.3.1 // indirect
go.mod: go get github.com/aliyun/alibaba-cloud-sdk-go@v1.63.107 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>
2025-10-21 16:26:49 -04:00
github.com/opentracing/opentracing-go v1.2.1-0.20220228012449-10b1cf09e00b // indirect
go.mod: Use the new "tool" directive 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>
2025-10-09 14:01:32 -04:00
github.com/pkg/browser v0.0.0-20240102092130-5ac0b6a4141c // indirect
go.mod: go get cloud.google.com/go/storage@v1.57.0 (#3385) Signed-off-by: Andrei Ciobanu <andrei.ciobanu@opentofu.org>
2025-10-17 11:16:53 -04:00
github.com/planetscale/vtprotobuf v0.6.1-0.20240319094008-0393e58bdf10 // indirect
go.mod: go get github.com/hashicorp/consul/api@v1.32.4 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>
2025-10-14 16:23:30 -04:00
github.com/pmezard/go-difflib v1.0.1-0.20181226105442-5d4384ee4fb2 // indirect
go.mod: go get go.opentelemetry.io/contrib/exporters/autoexport@v0.63.0 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>
2025-10-09 19:28:04 -04:00
github.com/prometheus/client_golang v1.23.0 // indirect
github.com/prometheus/client_model v0.6.2 // indirect
github.com/prometheus/common v0.65.0 // indirect
github.com/prometheus/otlptranslator v0.0.2 // indirect
github.com/prometheus/procfs v0.17.0 // indirect
build: Generate copyright headers automatically HashiCorp legal now requires a copyright claim in a comment at the top of every substantial file in this repository. If we don't add this ourselves then a bot will open a PR to add missing entries, but that process adds git history, pull request, and GitHub notification noise so instead we'll deal with it proactively as part of our usual code generation steps. This means that pull requests will fail their checks if there are any files that lack copyright headers, so we can deal with those before we merge rather than in a subsequent PR.
2023-05-08 19:02:22 -04:00
github.com/rivo/uniseg v0.2.0 // indirect
add OpenBao as key provider for state encryption (#1436) Signed-off-by: ollevche <ollevche@gmail.com>
2024-04-08 08:38:17 -04:00
github.com/ryanuber/go-glob v1.0.0 // indirect
build: Generate copyright headers automatically HashiCorp legal now requires a copyright claim in a comment at the top of every substantial file in this repository. If we don't add this ourselves then a bot will open a PR to add missing entries, but that process adds git history, pull request, and GitHub notification noise so instead we'll deal with it proactively as part of our usual code generation steps. This means that pull requests will fail their checks if there are any files that lack copyright headers, so we can deal with those before we merge rather than in a subsequent PR.
2023-05-08 19:02:22 -04:00
github.com/samber/lo v1.37.0 // indirect
go.mod: go get -u github.com/mitchellh/cli
2022-11-15 12:05:52 -05:00
github.com/shopspring/decimal v1.3.1 // indirect
github.com/spf13/cast v1.5.0 // indirect
build: Generate copyright headers automatically HashiCorp legal now requires a copyright claim in a comment at the top of every substantial file in this repository. If we don't add this ourselves then a bot will open a PR to add missing entries, but that process adds git history, pull request, and GitHub notification noise so instead we'll deal with it proactively as part of our usual code generation steps. This means that pull requests will fail their checks if there are any files that lack copyright headers, so we can deal with those before we merge rather than in a subsequent PR.
2023-05-08 19:02:22 -04:00
github.com/spf13/cobra v1.6.1 // indirect
go.mod: go get k8s.io/client-go@v0.34.1 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>
2025-10-20 12:11:20 -04:00
github.com/spf13/pflag v1.0.6 // indirect
go.mod: go get cloud.google.com/go/storage@v1.57.0 (#3385) Signed-off-by: Andrei Ciobanu <andrei.ciobanu@opentofu.org>
2025-10-17 11:16:53 -04:00
github.com/spiffe/go-spiffe/v2 v2.5.0 // indirect
go.mod: go get github.com/hashicorp/consul/api@v1.32.4 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>
2025-10-14 16:23:30 -04:00
github.com/stretchr/testify v1.11.1 // indirect
build: Generate copyright headers automatically HashiCorp legal now requires a copyright claim in a comment at the top of every substantial file in this repository. If we don't add this ourselves then a bot will open a PR to add missing entries, but that process adds git history, pull request, and GitHub notification noise so instead we'll deal with it proactively as part of our usual code generation steps. This means that pull requests will fail their checks if there are any files that lack copyright headers, so we can deal with those before we merge rather than in a subsequent PR.
2023-05-08 19:02:22 -04:00
github.com/thanhpk/randstr v1.0.4 // indirect
github.com/thlib/go-timezone-local v0.0.0-20210907160436-ef149e42d28e // indirect
go.mod: go get github.com/hashicorp/go-getter@v1.8.0 This is the first version of go-getter that uses AWS SDK for Go v2, instead of the now-obsolete SDK v1. This means that we no longer have an indirect dependency on the obsolete SDK version, and so should generate less noise for security scanners that are configured to check for unmaintained dependencies. This does unfortunately also force upgrading some of the AWS SDK v2 dependencies, which potentially affects the "s3" backend too. This is the typical risk of having all of these external integrations linked directly into our executables, but most of these are just minor upgrades that we likely would've adopted in the near future anyway. The newer version of go-getter also uses newer versions of some of its other dependencies, but we were already on newer versions of most of them anyway and so the main effect here is just to drop the older versions from our go.sum file now that they are no longer included in the module version selection process. Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
2025-09-15 12:02:01 -04:00
github.com/ulikunitz/xz v0.5.15 // indirect
go.mod: go get github.com/zclconf/go-cty@v1.3.2
2023-05-22 11:21:02 -04:00
github.com/vmihailenco/msgpack/v5 v5.3.5 // indirect
github.com/vmihailenco/tagparser/v2 v2.0.0 // indirect
go.mod: go get k8s.io/client-go@v0.34.1 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>
2025-10-20 12:11:20 -04:00
github.com/x448/float16 v0.8.4 // indirect
go.mod: go get cloud.google.com/go/storage@v1.57.0 (#3385) Signed-off-by: Andrei Ciobanu <andrei.ciobanu@opentofu.org>
2025-10-17 11:16:53 -04:00
github.com/zeebo/errs v1.4.0 // indirect
build: Generate copyright headers automatically HashiCorp legal now requires a copyright claim in a comment at the top of every substantial file in this repository. If we don't add this ourselves then a bot will open a PR to add missing entries, but that process adds git history, pull request, and GitHub notification noise so instead we'll deal with it proactively as part of our usual code generation steps. This means that pull requests will fail their checks if there are any files that lack copyright headers, so we can deal with those before we merge rather than in a subsequent PR.
2023-05-08 19:02:22 -04:00
go.mongodb.org/mongo-driver v1.11.6 // indirect
go.mod: Upgrade our various AWS SDK for Go dependencies 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>
2025-10-10 14:31:50 -04:00
go.opentelemetry.io/auto/sdk v1.2.1 // indirect
go.mod: go get go.opentelemetry.io/contrib/exporters/autoexport@v0.63.0 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>
2025-10-09 19:28:04 -04:00
go.opentelemetry.io/contrib/bridges/prometheus v0.63.0 // indirect
go.mod: go get cloud.google.com/go/storage@v1.57.0 (#3385) Signed-off-by: Andrei Ciobanu <andrei.ciobanu@opentofu.org>
2025-10-17 11:16:53 -04:00
go.opentelemetry.io/contrib/detectors/gcp v1.36.0 // indirect
go.mod: Upgrade our various AWS SDK for Go dependencies 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>
2025-10-10 14:31:50 -04:00
go.opentelemetry.io/contrib/instrumentation/github.com/aws/aws-sdk-go-v2/otelaws v0.63.0 // indirect
go.mod: go get cloud.google.com/go/storage@v1.57.0 (#3385) Signed-off-by: Andrei Ciobanu <andrei.ciobanu@opentofu.org>
2025-10-17 11:16:53 -04:00
go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc v0.61.0 // indirect
go.mod: go get go.opentelemetry.io/contrib/exporters/autoexport@v0.63.0 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>
2025-10-09 19:28:04 -04:00
go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploggrpc v0.14.0 // indirect
go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp v0.14.0 // indirect
go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetricgrpc v1.38.0 // indirect
go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttp v1.38.0 // indirect
go.opentelemetry.io/otel/exporters/otlp/otlptrace v1.38.0 // indirect
go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc v1.38.0 // indirect
go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp v1.38.0 // indirect
go.opentelemetry.io/otel/exporters/prometheus v0.60.0 // indirect
go.opentelemetry.io/otel/exporters/stdout/stdoutlog v0.14.0 // indirect
go.opentelemetry.io/otel/exporters/stdout/stdoutmetric v1.38.0 // indirect
go.opentelemetry.io/otel/exporters/stdout/stdouttrace v1.38.0 // indirect
go.opentelemetry.io/otel/log v0.14.0 // indirect
go.mod: go get go.opentelemetry.io/otel/sdk@v1.39.0 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>
2025-12-16 17:58:04 -05:00
go.opentelemetry.io/otel/metric v1.39.0 // indirect
go.mod: go get go.opentelemetry.io/contrib/exporters/autoexport@v0.63.0 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>
2025-10-09 19:28:04 -04:00
go.opentelemetry.io/otel/sdk/log v0.14.0 // indirect
go.mod: go get go.opentelemetry.io/otel/sdk@v1.39.0 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>
2025-12-16 17:58:04 -05:00
go.opentelemetry.io/otel/sdk/metric v1.39.0 // indirect
go.mod: go get go.opentelemetry.io/contrib/exporters/autoexport@v0.63.0 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>
2025-10-09 19:28:04 -04:00
go.opentelemetry.io/proto/otlp v1.7.1 // indirect
go.mod: go get k8s.io/client-go@v0.34.1 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>
2025-10-20 12:11:20 -04:00
go.yaml.in/yaml/v2 v2.4.2 // indirect
go.yaml.in/yaml/v3 v3.0.4 // indirect
go.mod: go get github.com/hashicorp/consul/api@v1.32.4 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>
2025-10-14 16:23:30 -04:00
golang.org/x/exp v0.0.0-20250808145144-a408d31f581a // indirect
build: Use Go 1.20.0 This changes which Go version we use for official releases and for everyday development and testing. At the time of this commit Go 1.20.1 is available but is not yet included in goenv, the tool that we use in some environments for reacting automatically to this file. I expect we'll upgrade to Go 1.20.1 very soon, but this is a routine upgrade to the latest major release so that we can start soaking in the new compiler and library behaviors throughout the v1.5 development period. Go 1.20 continues to support only Unicode 13, so we do not need to make any changes to our supporting packages that also rely on Unicode data.
2023-02-14 20:48:43 -05:00
golang.org/x/exp/typeparams v0.0.0-20221208152030-732eee02a75a // indirect
go.mod: go get cloud.google.com/go/kms@v1.23.2 && go get google.golang.org/api@v0.252.0 (#3410) Signed-off-by: Andrei Ciobanu <andrei.ciobanu@opentofu.org>
2025-10-22 08:28:42 -04:00
golang.org/x/time v0.13.0 // indirect
go.mod: Routine upgrades of golang.org/x/* modules 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>
2026-01-12 14:34:49 -05:00
golang.org/x/tools v0.40.0 // indirect
go.mod: go get cloud.google.com/go/storage@v1.57.0 (#3385) Signed-off-by: Andrei Ciobanu <andrei.ciobanu@opentofu.org>
2025-10-17 11:16:53 -04:00
google.golang.org/genproto v0.0.0-20250603155806-513f23925822 // indirect
go.mod: go get go.opentelemetry.io/contrib/exporters/autoexport@v0.63.0 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>
2025-10-09 19:28:04 -04:00
google.golang.org/genproto/googleapis/api v0.0.0-20250825161204-c5933d9347a5 // indirect
go.mod: go get cloud.google.com/go/kms@v1.23.2 && go get google.golang.org/api@v0.252.0 (#3410) Signed-off-by: Andrei Ciobanu <andrei.ciobanu@opentofu.org>
2025-10-22 08:28:42 -04:00
google.golang.org/genproto/googleapis/rpc v0.0.0-20251002232023-7c0ddcbb5797 // indirect
go.mod: Use the new "tool" directive 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>
2025-10-09 14:01:32 -04:00
google.golang.org/grpc/cmd/protoc-gen-go-grpc v1.3.0 // indirect
go.mod: go get k8s.io/client-go@v0.34.1 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>
2025-10-20 12:11:20 -04:00
gopkg.in/evanphx/json-patch.v4 v4.12.0 // indirect
update k8s packages from retracted module Use the latest k8s.io packages from v0.21
2021-11-16 14:42:06 -05:00
gopkg.in/inf.v0 v0.9.1 // indirect
go.mod: go get github.com/aliyun/alibaba-cloud-sdk-go@v1.63.107 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>
2025-10-21 16:26:49 -04:00
gopkg.in/ini.v1 v1.67.0 // indirect
Save detailed type outputs to JSONStateOutputs
2022-07-18 15:15:37 -04:00
gopkg.in/yaml.v3 v3.0.1 // indirect
go.mod: Use the new "tool" directive 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>
2025-10-09 14:01:32 -04:00
honnef.co/go/tools v0.4.2 // indirect
go.mod: go get k8s.io/client-go@v0.34.1 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>
2025-10-20 12:11:20 -04:00
k8s.io/klog/v2 v2.130.1 // indirect
k8s.io/kube-openapi v0.0.0-20250710124328-f3f2b991d03b // indirect
sigs.k8s.io/json v0.0.0-20241014173422-cfa47c3a1cc8 // indirect
sigs.k8s.io/randfill v1.0.0 // indirect
sigs.k8s.io/structured-merge-diff/v6 v6.3.0 // indirect
sigs.k8s.io/yaml v1.6.0 // indirect
Add kubernetes backend Co-authored-by: Dan Ramich <danold215@gmail.com>
2020-04-13 16:17:17 -04:00
)
Bump our hcl fork to include fix for Provider defined functions in parentheses (#3402) Signed-off-by: James Humphries <james@james-humphries.co.uk>
2025-10-22 05:40:53 -04:00
replace github.com/hashicorp/hcl/v2 v2.20.1 => github.com/opentofu/hcl/v2 v2.20.2-0.20251021132045-587d123c2828
go.mod: Use the new "tool" directive 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>
2025-10-09 14:01:32 -04:00
tool (
github.com/hashicorp/copywrite
github.com/mitchellh/gox
go.mod: List our own tools in the "tools" directive 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>
2026-01-08 12:32:18 -05:00
github.com/opentofu/opentofu/cmd/tofu
github.com/opentofu/opentofu/tools/find-dep-upgrades
github.com/opentofu/opentofu/tools/loggraphdiff
github.com/opentofu/opentofu/tools/protobuf-compile
Remove last remnants of ".go-version" file 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>
2026-01-19 11:57:29 -05:00
github.com/opentofu/opentofu/tools/selected-go-version
go.mod: Use the new "tool" directive 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>
2025-10-09 14:01:32 -04:00
go.uber.org/mock/mockgen
golang.org/x/tools/cmd/stringer
google.golang.org/grpc/cmd/protoc-gen-go-grpc
google.golang.org/protobuf/cmd/protoc-gen-go
honnef.co/go/tools/cmd/staticcheck
)
Reference in a new issue Copy permalink