OpenTofu Release Notes

BUG FIXES

• Properly handle TF_ENCRYPTION with only blank spaces. (#4265)
• The value resulted from the lifecycle.enabled evaluation now has its deprecation marks processed correctly (#4162)
• Update documentation to clarify the usage restriction of ephemeral values in lifecycle.enabled. (#4220)
• tofu console -lock=false now works as intended. (#4291)

SECURITY ADVISORIES

• Previous releases in the v1.12 series could read an arbitrary file during certain git operations via a maliciously crafted URL (#4293)
  • Advisory: GHSA-q7j3-v8qv-22vq

Full Changelog: v1.12.2...v1.12.3

Original source

SECURITY ADVISORIES:

• Previous releases in the v1.12 series could be affected by several vulnerabilities:

  • If for state encryption, OpenBao key provider is used with wrapping algorithms, it could generate panics or hangs on compromised systems where the JWE is specifically crafted.
    This is fixed now by (#4177)

• Previous releases in the v1.12 series could be affected by several vulnerabilities:

  • When using SSH connections through OpenTofu, the errors that were returned from attempting a connection could include unescaped input bytes.
  • If using an attacker-controlled server to run tofu against, it might end up in high CPU consumption.
    These are now fixed by (#4247)

BUG FIXES:

• Properly handle EDEADLK during provider installation. On Unix systems, the kernel may erroneously detect a deadlock between tofu processes using the global plugin cache. (#4166)
• Fix race condition while handling closing signals during tofu login, both when the signal is sent by the user and when the browser fails to successfully connect. (4016)
• Prevent panic when using ephemeral resources during tofu test`. (#4254)

Full Changelog: v1.12.1...v1.12.2

Original source

SECURITY ADVISORIES

• Previous releases in the v1.11 series could be affected by several vulnerabilities:

  • ssh usage through OpenTofu generate hangs or panics.
  • Previously, a revoked 'SignatureKey' belonging to a CA was not correctly checked for revocation. Now, both the 'key' and 'key.SignatureKey' are checked for @Revoked.
    This is fixed now by (#4145)

• If for state encryption, OpenBao key provider is used with wrapping algorithms, it could generate panics or hangs on compromised systems where the JWE is specifically crafted. (#4177)

• Previous releases in the v1.11 series could be affected by several vulnerabilities:

  • When using SSH connections through OpenTofu, the errors that were returned from attempting a connection could include unescaped input bytes.
  • If using an attacker-controlled server to run tofu against, it might end up in high CPU consumption.
    These are now fixed by (#4248)

BUG FIXES

• Fix race condition while handling closing signals during tofu login, both when the signal is sent by the user and when the browser fails to successfully connect. (4016)

• Prevent panic when using ephemeral resources during tofu test`. (#4254)

Full Changelog: v1.11.8...v1.11.9

Original source

Here are some highlights from the new features in this release:

• Dynamic prevent_destroy: The prevent_destroy argument in a resource's lifecycle block can now refer to other symbols within the same module, such as input variables.
• Improved provider checksum handling: tofu init now automatically includes a full set of checksums for all platforms using both zh: and h1: hashes, reducing the need for manually running tofu providers lock.
• Simultaneous output formats: The new -json-into=FILENAME CLI option allows saving machine-readable output to a separate file while still producing human-readable output in the terminal.
• New destroy lifecycle meta-argument: The new destroy = false lifecycle option for managed resources allows removing an object from the state without first destroying the remote object.
• Provider installer performance: Provider installation now performs concurrent requests for faster tofu init completion when many providers are needed.

For more information, refer to the v1.12.0 release announcement and the v1.12 series changelog.

Compatibility Notes

• New h1: checksums in dependency lock file: Due to the improved provider checksum handling in this release, the first time you run tofu init after upgrading you are likely to find additional h1: checksums have been added for any providers that were already tracked in your dependency lock file.

This behavior is an example of what's described in New provider package checksums: the newly-added checksums each match one of the zh: checksums previously recorded and represent the same information in a different way. In OpenTofu v1.12 this is now a one-time backfill of all of the official checksums, rather than "upgrading" them one-by-one as in earlier versions.

• WinRM connections for provisioners are deprecated: Provisioner connection blocks with type = "winrm" will now cause warnings in this release, and will no longer be supported at all in OpenTofu v1.13.

We recommend migrating to OpenSSH for Windows.

• Phasing out support for 32-bit CPU architectures: In a future release we plan to stop providing official release builds for the 32-bit 386 and arm CPU architectures. Support for amd64 and arm64 is unaffected.

There is no immediate change to supported platforms in the v1.12 series, but we expect to introduce a deprecation warning in v1.13 and then stop providing official builds for these architectures completely in a future release series. If you don't expect that you'll be able to complete a migration to running on a 64-bit architecture in the next year, please tell us about your situation in issue #3912.

Original source

Previous releases in the v1.12 series could be affected by several vulnerabilities:

• ssh usage through OpenTofu generate hangs or panics.
• Previously, a revoked 'SignatureKey' belonging to a CA was not correctly checked for revocation. Now, both the 'key' and 'key.SignatureKey' are checked for @revoked.

This is fixed now by (#4145).

BUG FIXES

• Address a bug introduced in v1.12.0 causing excessive memory usage by providers. (#4126)
• Address a bug introduced in v1.12.0 where replace_triggered_by was validated incorrectly. (#4133)
• The Azure key provider will now accept the tenant_id, subscription_id, environment, and metadata_host variables; a bug previously only allowed these to be set through environment variables. (#4091)

Full Changelog: https://github.com/opentofu/opentofu/blob/v1.12/CHANGELOG.md

Original source

We're proud to announce that OpenTofu 1.12.0 is now officially available! 🎉

Highlights

This release cycle introduces major new capabilities and integrations:

Dynamic prevent_destroy

OpenTofu v1.12.0 now allows prevent_destroy to be defined dynamically in terms of other values available elsewhere in the same module. For example:

variable "prevent_destroy_database" {
  type = bool
  default = true
}
resource "example_database" "example" {
  # ...
  lifecycle {
    prevent_destroy = var.prevent_destroy_database
  }
}

Provider Checksum Improvements

The default provider installation behavior in OpenTofu is designed to mostly "just work" by getting the needed providers installed and making the necessary changes to the dependency lock file, but in previous versions friction appeared for any teams using many of the non-default installation settings such as the shared provider plugin cache, or local mirrors of upstream providers.

For OpenTofu v1.12, OpenTofu Registry now provides a full set of official checksums in all of the checksum formats needed by other installation methods. This means that after running tofu init the dependency lock file will immediately have all of the information required to successfully use a global plugin cache directory and to verify matching packages served from a local mirror, without needing to run tofu providers lock separately.

Simultaneous Human-readable and Machine-readable Output

Many OpenTofu commands support both human-oriented UI output and machine-readable JSON output, but previously those commands could be run with only one or the other. This was bothersome for those implementing alternative UIs in terms of the machine-readable output because it meant they would need to implement all possible features of the UI before their tool could actually be used.

OpenTofu v1.12.0 introduces a new option -json-into=FILENAME, which produces the same output format that -json would have produced but sends that output to the given filename instead of to the standard output stream. The OpenTofu UI output then appears on the standard output stream as normal, so that software interpreting the JSON output can behave as just a supplement to the normal UI rather than a complete replacement.

New destroy lifecycle meta-argument

New destroy lifecycle meta-argument

The new destroy = false lifecycle option for managed resources allows removing an object from the state without first destroying the remote object.

Deprecation Notices

WinRM for Provisioners is Now Deprecated

Some of the Go libraries that OpenTofu uses for WinRM connection support in provisioners have become unmaintained over time, and so unfortunately we are phasing out support for WinRM in OpenTofu starting with deprecation warnings in this release.

If your configuration includes a connection block with type = "winrm" then OpenTofu v1.12 will warn that this connection type is deprecated, but provisioning should otherwise still work as it did before.

We intend to remove WinRM support completely in the forthcoming OpenTofu v1.13 series, and so if you are currently relying on WinRM support we recommend that you begin planning to migrate to using OpenSSH for Windows instead.

Phasing Out Support for 32-bit CPU Architectures

We are also planning to stop producing official releases for 32-bit CPU architectures (386 and arm) in a future version of OpenTofu. Support for 64-bit architectures (amd64 and arm64) is unaffected.

OpenTofu v1.12 does not include any changes to CPU support yet, but we expect that the official builds in the forthcoming v1.13 series will begin producing warnings when running on 32-bit CPU architectures, before we stop producing those packages altogether in a future release series.

Compatibility Notes

• macOS: Requires macOS 12 Monterey or later
• The OPENTOFU_USER_AGENT environment variable, which allowed fully overriding the default User-Agent header on all HTTP requests, has been removed.
• On Unix systems OpenTofu now considers the BROWSER environment variable as a possible override for the default behavior for launching a web browser. If you run OpenTofu in a context where an environment variable of that name is already set, it may cause OpenTofu to now open a web browser in a different way than previous versions would have. Unsetting that environment variable will restore the previous platform-specific behavior.

Reference

• Full Changelog
• Blog Post

Thank you for your continued support and testing of the OpenTofu project!

Original source

Today we've released OpenTofu v1.12.0, collecting together several months of work from the OpenTofu community, including several new features.

The following are highlights from the new release:

• Dynamic prevent_destroy: The prevent_destroy argument in a resource's lifecycle block can now refer to other symbols within the same module, such as input variables.
• Improved provider checksum handling: tofu init now automatically includes a full set of checksums for all platforms using both zh: and h1: hashes, reducing the need for manually running tofu providers lock.
• Simultaneous output formats: The new -json-into=FILENAME CLI option allows saving machine-readable output to a separate file while still producing human-readable output in the terminal.
• New destroy lifecycle meta-argument: The new destroy = false lifecycle option for managed resources allows removing an object from the state without first destroying the remote object.
• Provider installer performance: Provider installation now performs concurrent requests for faster tofu init completion when many providers are needed.

For full details on the changes in this release, refer to the OpenTofu v1.12.0 release notes.

There are also some deprecations that might be relevant to you:

• WinRM for provisioners is deprecated
• Phasing out official builds for 32-bit CPU architectures

prevent_destroy can now be set dynamically

The prevent_destroy lifecycle argument for managed resources tells OpenTofu that it should return an error if the plan for a particular object involves destroying it. Authors tend to use this feature for infrastructure objects that whose deletion would cause large disruption, or when faithfully recreating that object would require manual action outside of OpenTofu such as restoring a backup.

Unfortunately this setting previously required making a static decision that's hard-coded into the configuration, which is annoying for shared modules that might be used in multiple different environments that have different needs. For example, it's common to want to make it very hard to destroy a production database while still allowing the equivalent database in a development environment to be easily replaced when necessary.

OpenTofu v1.12.0 now allows prevent_destroy to be defined dynamically in terms of other values available elsewhere in the same module. For example:

variable "prevent_destroy_database" {
  type = bool
  default = true
}

resource "example_database" "example" {
  # ...

  lifecycle {
    prevent_destroy = var.prevent_destroy_database
  }
}

A module containing the above would prevent deletion of the database by default, but when used in a development environment you could set prevent_destroy_database = false in the module block to disable that constraint.

This is the first of several other lifecycle-related settings we're hoping to make more dynamic in future versions of OpenTofu. We started with this one because the design questions for it had relatively straightforward answers. The others each have their own design challenges we need to overcome, and if you're interested you can find out more in the umbrella issue #1329.

Provider Checksum Improvements

The default provider installation behavior in OpenTofu is designed to mostly "just work" by getting the needed providers installed and making the necessary changes to the dependency lock file, but in previous versions friction appeared for any teams using many of the non-default installation settings such as the shared provider plugin cache, or local mirrors of upstream providers.

For OpenTofu v1.12, OpenTofu Registry now provides a full set of official checksums in all of the checksum formats needed by other installation methods. This means that after running tofu init the dependency lock file will immediately have all of the information required to successfully use a global plugin cache directory and to verify matching packages served from a local mirror, without needing to run tofu providers lock separately.

The tofu providers lock command is now needed only in the situation for which it was originally intended: populating the dependency lock file with the official checksums from origin registries on systems where tofu init has been reconfigured to use an alternative installation source. As long as your CLI configuration allows tofu init to install providers directly from OpenTofu Registry (which is the default), it will record the full set of checksums automatically.

The first time you run tofu init after upgrading, you will find additional entries were added to the hashes argument in your dependency lock file, all of which should use the h1: prefix. This is the hashing scheme that previous versions of OpenTofu could only calculate locally, but OpenTofu v1.12 can now prepopulate all of these hashes at once on first install in addition to the zh: hashes that were already included by previous versions of OpenTofu.

Simultaneous Human-readable and Machine-readable Output

Many OpenTofu commands support both human-oriented UI output and machine-readable JSON output, but previously those commands could be run with only one or the other. This was bothersome for those implementing alternative UIs in terms of the machine-readable output because it meant they would need to implement all possible features of the UI before their tool could actually be used.

OpenTofu v1.12.0 introduces a new option -json-into=FILENAME, which produces the same output format that -json would have produced but sends that output to the given filename instead of to the standard output stream. The OpenTofu UI output then appears on the standard output stream as normal, so that software interpreting the JSON output can behave as just a supplement to the normal UI rather than a complete replacement.

For commands that produce streaming JSON output describing a series of ongoing events, you can optionally specify the path to an operating system IPC object such as a named pipe or a /dev/fd/N special device node so that your software can consume that JSON output concurrently with OpenTofu's execution, such as if you want to update a web UI or terminal UI responsively to report ongoing progress.

Download and Install

You can download OpenTofu v1.12.0 directly from our GitHub releases page, install it using your preferred package manager, or use our official Docker images.

For more information, refer to our installation guides.

Deprecation Notices

WinRM for Provisioners is Now Deprecated

Some of the Go libraries that OpenTofu uses for WinRM connection support in provisioners have become unmaintained over time, and so unfortunately we are phasing out support for WinRM in OpenTofu starting with deprecation warnings in this release.

If your configuration includes a connection block with type = "winrm" then OpenTofu v1.12 will warn that this connection type is deprecated, but provisioning should otherwise still work as it did before.

We intend to remove WinRM support completely in the forthcoming OpenTofu v1.13 series, and so if you are currently relying on WinRM support we recommend that you begin planning to migrate to using OpenSSH for Windows instead.

Phasing Out Support for 32-bit CPU Architectures

We are also planning to stop producing official releases for 32-bit CPU architectures (386 and arm) in a future version of OpenTofu. Support for 64-bit architectures (amd64 and arm64) is unaffected.

OpenTofu v1.12 does not include any changes to CPU support yet, but we expect that the official builds in the forthcoming v1.13 series will begin producing warnings when running on 32-bit CPU architectures, before we stop producing those packages altogether in a future release series.

If you are currently running OpenTofu on a 32-bit CPU architecture we recommend beginning to plan migration to a 64-bit architecture instead. If you don't expect to be able to complete that migration at some point in the next year, please tell us about your situation in issue #3912.

Original source

BUG FIXES

• Running tofu apply -refresh-only with a configuration that contains ephemeral resources does not fail anymore because the refresh produced changes (#3776)
• Fixed tofu init crashing when a module version uses a variable and the module is referenced from a test file. (#3686)
• Fixed provider-defined functions in import block id expressions causing "BUG: Uninitialized function provider" error. (#3803)
• tofu test no longer fails during cleanup when using a mocked version of a resource type with write-only attributes. (#3964)
• A malicious remote TLS server can no longer deadlock OpenTofu by sending multiple key update messages in a single record. (#3966)
• When installing module packages from "tar" archives, OpenTofu now accepts only a limited number of sparse file entries to avoid unbounded memory usage from maliciously-crafted archives containing many sparse regions. (#3966)

Full Changelog: v1.11.5...v1.11.6

Original source

We've now published the first beta release of OpenTofu 1.12.0. For this cycle we intentionally worked mainly on smaller enhancements and fixes, since it's otherwise easy for those to get left behind when we prioritize larger features. Nonetheless, there are some commonly-requested improvements here that we hope you'll enjoy.

Warning

Do not use OpenTofu prereleases in production environments!

Download and Installation

Download the appropriate package for your platform:

Platform Release Package macOS (Apple Silicon) tofu_1.12.0-beta1_darwin_arm64.zip Linux (AMD64) tofu_1.12.0-beta1_linux_amd64.zip Linux (ARM64) tofu_1.12.0-beta1_linux_arm64.zip Windows (AMD64) tofu_1.12.0-beta1_windows_amd64.zip

We also provide packages for some other platforms on a best-effort basis. For more information, refer to the full set of release packages.

After downloading, extract the archive to find the tofu executable.

What's New in OpenTofu 1.12

The following sections describe some highlights of this release. For the full set of changes in this release, refer to the OpenTofu v1.12 changelog.

prevent_destroy can now be set dynamically

The prevent_destroy argument for managed resources can now refer to input variables and other dynamic symbols, so for example you can write a module that refuses deletion of an important object by default but allow the caller to override that in development environments:

variable "prevent_destroy_database" {
  type = bool
  default = true
}

resource "example_database" "example" {
  # ...
  lifecycle {
    prevent_destroy = var.prevent_destroy_database
  }
}

A caller of the above module could explicitly set prevent_destroy_database = false to allow tofu destroy to work, but this would still cause an error by default to reduce the risk of mistakes.

Import using "Resource Identity"

The latest versions of the provider plugin protocol introduce a new concept called "resource identity", which allows each resource type to have a schema for just a small amount of metadata that uniquely identifies an object in the remote system, as opposed to the main state data that includes all of the attributes you can normally interact with in OpenTofu modules.

OpenTofu v1.12 introduces our first major use of that new feature: import using resource identity. Traditionally the tofu import command and import blocks required identifying the object to import with just a single string assigned to the id argument, which is okay for simple cases where the remote object has a single string as its unique identifier but is challenging for resource types where the identifier is some sort of compound key, where previously each resource type needed its own special syntax for how to identify a remote object.

import blocks now support a new identity argument which module authors would use instead of id argument to describe what to import using an object that matches the resource type's resource identity schema.

For example, aws_ssm_maintenance_window_target from the hashicorp/aws provider has a resource identity schema that requires both id and window_id attributes to be specified, and so now you can write an import block like this:

import {
  to = aws_ssm_maintenence_window_target.example
  identity = {
    window_id = "mw-EXAMPLE"
    id = "20591c06-c386-41ac-928c-5cc32dd43cd9"
  }
}

For the simpler resource types whose import id format was previously just a simple identifier, their identity schema usually just includes a single required attribute whose name describes what kind of identifier is required. For example, in the hashicorp/aws provider it's common to use an arn attribute whose value is the fully-qualified ARN for the object.

A provider decides what schema to use for each of its resource types. To find out whether a resource type has been updated to support import by resource identity, and which attributes to use if so, refer to the documentation for the resource type you are interested in using the OpenTofu Registry. Most resource types continue to support the original style of import with just a single id string too, but that is technically optional and so over time providers may stop offering that for new resource types.

Provider Installation Improvements

OpenTofu Registry now returns a full set of checksums when you install a provider, so that the dependency lock file will immediately have enough information to verify packages on all of the platforms the provider supports.

Although previous versions of OpenTofu were able to produce a working dependency lock file when using the default provider installation settings, many of the available customizations of the installation process caused problems related to checksums:

• The checksums returned by the registry could not be used to verify packages in the optional global cache directory, so that cache was often ineffective at preventing OpenTofu from redownloading packages from the origin registry.
• The checksums returned by the registry could also not verify packages from local filesystem mirror directories or other alternative installation methods, which caused tofu init to fail when run on a platform other than the one that initially populated the lock file, unless teams remembered to explicitly run tofu providers lock to force adding additional checksums to the lock file.
• Even with the default settings, running tofu init on a different platform than where it was initially run would cause an additional checksum to be added to the lock file, which is confusing for anyone reviewing changes to the configuration and is particularly problematic for those who use tofu init -lockfile=readonly in their pipeline to ensure that only previously-reviewed providers can be selected.

To avoid these problems, the registry now returns checksums that are suitable for verifying both local and remote provider packages, and tofu init will add them all to the dependency lock file immediately if the downloaded package matches the reported checksums for the current platform.

In particular, most teams should no longer need to use tofu providers lock at all. We've retained it only for its originally-intended purpose: populating the lock file with correct checksums from the origin registry on a system where tofu init is configured to use an alternative installation source. As long as your CLI configuration allows tofu init to install packages directly from from OpenTofu Registry (which is the default), it will record the full set of checksums automatically.

The first time you run tofu init after upgrading, you are likely to find additional entries were added to the hashes argument in your dependency lock file, all of which should use the h1: prefix. This is the hashing scheme that previous versions of OpenTofu could only calculate locally, but OpenTofu v1.12 can now prepopulate all of these hashes at once on first install, in addition to the zh: hashes that were already included by previous versions of OpenTofu. If you already had a lock file entry for a provider that was populated from the registry by a previous version of OpenTofu then it should already have its full set of zh: checksums and so no new items should be added with that prefix.

Alongside the checksum-related changes, we've also made some performance improvements that should allow tofu init to complete faster for those who are installing many small providers.

Simultaneous Human-readable and Machine-readable Command Output

Various OpenTofu commands allow specifying a -json option on the command line to select machine-readable output in JSON format, instead of the normal human-oriented output. However, in previous versions these two modes were mutually-exclusive: requesting machine-readable output disabled the human-oriented output.

OpenTofu v1.12 introduces the alternative -json-into=FILE option, which leaves the human-oriented output enabled on the "stdout" and "stderr" handles but also writes the machine-readable output to the specified file. We expect this would be useful for those running OpenTofu in pipelines where the human-facing output should appear in the main job output for operators to read, but the pipeline also needs access to some or all of that information for automation purposes. The specified path can either refer to a regular file or to a special object like a named pipe or "FIFO", in case your automation needs to react to streaming events concurrently while OpenTofu is still running.

We've also introduced the -json and -json-into=FILE options to many more commands in this release. For most of these the JSON output is currently just human-oriented messages wrapped up in JSON objects, but we're interested in extending these JSON objects with useful data based on your use-cases. If there's some specific automation or an alternative UI you'd like to build that would benefit from machine-readable information about what OpenTofu is working on, please open a feature request issue on GitHub and we'll consider it for a future release.

Join the Testing Effort

Your testing and feedback are crucial to ensuring that these new capabilities work correctly across different environments and use cases.

If you have a strong non-production environment where you could test any of the new features or bugfixes then we'd appreciate your help. Even if everything works as you expected, please share your testing experiences or join the conversation in #opentofu in the CNCF Slack workspace.

Thank you for supporting the OpenTofu project!

Original source