OpenTofu Release Notes

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

Highlights

Windows on ARM64 is now a supported platform

Starting with OpenTofu v1.13.0 we are now offering official packages targeting Windows on the ARM64 (also known as "aarch64") CPU architecture.

Reducing unknowns during planning

OpenTofu v1.13 introduces a number of new functions that are all intended to allow module authors to give OpenTofu additional hints about what they know to be true even though OpenTofu cannot infer it automatically.

Linting Experiment

OpenTofu v1.13 includes some very early work towards built-in "linting" features in OpenTofu, although we are hoping to eventually incorporate other similar needs such as policy enforcement into a single comprehensive feature.

Symbol Libraries Experiment

We're considering a new kind of artifact called a "Symbol Library", which is a reusable collection of values, functions, and type aliases that can be imported from all of the same source types that are already supported for modules.

Compatibility Notes

• base64gzip produces results that are equivalent but not byte-for-byte identical to previous versions, this is due to a required golang version upgrade
• WinRM is no longer supported for provisioners
• macOS: Requires macOS 13 Ventura or later
• OpenTofu v1.13 will be the last series that includes official releases for 32 bit CPUs

Reference

• Full Changelog
• Blog Post

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

Original source

Windows on ARM64 is now a supported platform

We've just published OpenTofu v1.13.0!

We intentionally shortened the development period for v1.13.0 so that we're now more closely aligned with the Go release cycle, which means that we maximize the length of time this series can remain under security support: this series will be supported until August 2027.
However, that means that this is a relatively light release in terms of new features. The following are some highlights from the new release:

• Official releases for Windows running on ARM64 CPUs
• convert and assume... functions for reducing unknowns during planning
• Some early, experimental work towards built-in linting
• An experimental first pass of a planned new feature called "Symbol Libraries"

There are also some important changes to existing behavior that may be relevant to you:

• base64gzip function now produces slightly different results
• WinRM is no longer supported for provisioners
• Phasing out official builds for 32-bit CPU architectures
• OpenTofu on macOS now requires macOS 13 Ventura or later

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

Starting with OpenTofu v1.13.0 we are now offering official packages targeting Windows on the ARM64 (also known as "aarch64") CPU architecture.
This has admittedly been a long time coming, and took a while both because we lacked infrastructure for routinely testing on this platform and because we needed to wait for provider plugin support to be established before such releases would be useful.
Most of OpenTofu's builds of the various major cloud platform providers have windows_arm64-targeted packages available, but note that maintainers of third-party providers in OpenTofu Registry set their own policy for which platforms to support and so you may need to upgrade to a new version of a provider you've previously used, and some providers may not yet support this platform at all.

Reducing unknowns during planning

OpenTofu's core workflow relies on predicting as close as possible what will happen during the apply phase so that it can present you with a set of proposed changes during the planning phase. In practice though, various values cannot be completely predicted during the planning phase, and so OpenTofu uses the concept of "unknown values" -- which appear as (known after apply) in the plan output -- to resolve as much as possible while also being clear about what it doesn't know yet.
Unfortunately there are a number of situations where unknown values are inconvenient or can even block progress. There are several OpenTofu features that currently reject values that are not known during the planning phase, such as the enabled, for_each, and count meta-arguments. Separately, some teams run the machine-readable form of the plan output through automatic policy-checking software which is effectively blinded by unknown values and therefore faces a difficult decision between either optimistically allowing it (with the risk that the final values will violate policy) or conservatively blocking it (risking that it'll block changes that would actually have conformed to the policy).

To offer a new form of compromise, OpenTofu v1.13 introduces a number of new functions that are all intended to allow module authors to give OpenTofu additional hints about what they know to be true even though OpenTofu cannot infer it automatically:

• convert allows you to hint to OpenTofu what type of result is expected, in situations where that's not predictable.

For example, passing an unknown string to jsondecode usually causes an unknown result of an unknown type, but you may actually know what shape the JSON is expected to be and so could specify it so downstream expressions can rely on that additional information:

output "example" {
  value = convert(jsondecode(something_dynamic.example.output_json), object({
    id = string
    tags = map(string)
  }))
}

If something_dynamic.example.output_json is unknown during planning then the result is still an unknown value, but it's at least an unknown value where OpenTofu knows that accessing the id attribute would produce a string, etc.

• The assume... family of functions allow you to give hints about the value itself, such as declaring that it will definitely not be null or that it is a string which definitely has a specific prefix.

For example, it's a common annoyance that most resource types in the hashicorp/aws provider return an unknown id attribute when planning the creation of a remote object, which means that comparing that attribute to null or to the empty string produces an unknown value, which makes it harder to use the result with another module which uses the nullness of an input variable to decide whether to enable something.

output "vpc_id" {
  value = assumenotnull(
    assumestringprefix(
      aws_vpc.example.id,
      "vpc-",
    )
  )
}

Any expression which compares this output value to null or to "" will therefore be able to produce a known false instead of an unknown boolean result. If this value were passed to a module that has a validation rule where the given VPC ID is required to have the prefix vpc- then that would be validated during the plan phase instead of the apply phase so you can get feedback about mistakes sooner.
All of this comes with a significant requirement, though: the module author must be sure that whatever hint they are offering will actually be true during the apply phase. If you promise OpenTofu that an unknown string will have the prefix vpc- and it ends up having the prefix subnet- then the assumestringprefix call will fail during the apply phase. But in situations where the provider documentation or underlying vendor API documentation guarantees something, this can be a good way to let users of your module rely on that guarantee even when the provider itself doesn't provide the relevant hints itself, thereby keeping the workaround for the imprecise plan encapsulated in a shared module.

Linting Experiment

OpenTofu v1.13 includes some very early work towards built-in "linting" features in OpenTofu, although we are hoping to eventually incorporate other similar needs such as policy enforcement into a single comprehensive feature.
For this first release we've just got some of the internal infrastructure for representing which lint rules are enabled and for reporting lint results back to the operator as warnings. There are some initial built-in rules relating to features of the OpenTofu language included as examples.
You can find out more about what we're hoping to achieve with this set of features in future releases, and about the initial experimental functionality included in v1.13.0, in our separate blog post: A Vision for Built-in Linting. If you are interested in built-in linting and policy features, we'd love to hear your feedback! There's more information in the other blog post about how you could contribute.

Symbol Libraries Experiment

A common frustration from OpenTofu configuration authors is that there are various pieces of shared data or functionality that they'd like to share across many modules and many configurations, but OpenTofu's main unit of reuse -- shared modules -- is designed for sharing definitions of stateful resources, not for sharing arbitrary data and logic.
In answer to that frustration we're considering a new kind of artifact called a "Symbol Library", which is a reusable collection of values, functions, and type aliases that can be imported from all of the same source types that are already supported for modules.
For example, you could write a symbol library representing a cross-cutting representation of DNS records and your organization's conventions for using them, which you could then import from multiple different modules to help ensure that they all "talk the same language" when integrated together into your overall configuration.
The specific language elements used here are just a starting point which we expect to continue evolving based on your feedback. You can find out more about this experiment in our separate blog post: An Introduction to OpenTofu Symbol Libraries.
If you're interested in this feature -- and especially if you try out the experimental form of it during the v1.13 series -- then we'd love to hear your feedback! There's more information in the other blog post about how you could contribute.

base64gzip implementation changes

OpenTofu is written in the Go programming language and offers a built-in function base64gzip which is implemented in terms of a gzip implementation in the Go standard library.
The upstream implementation of this function was changed in a way that causes it to now produce results that are equivalent but not byte-for-byte identical to previous versions. Therefore if you've used base64gzip in the definition of a resource argument in your configuration OpenTofu may indicate that the argument needs to change after you upgrade to OpenTofu v1.13.0 or later.
If you're using base64gzip in a context where you cannot immediately accept that change, we recommend temporarily using the ignore_changes meta-argument to tell OpenTofu to retain the previous value for now. You can remove that argument again once you're ready to change to the new gzip result.
As an alternative temporary workaround, an OpenTofu provider compiled with Go v1.26 or earlier could provide equivalent functions based on the previous implementation. The OpenTofu project does not have an official provider for this purpose, but third-party providers may be published in OpenTofu Registry.

WinRM is no longer supported for provisioners

With the OpenTofu v1.12.0 release we preannounced that WinRM support was deprecated and planned for removal, and now v1.13.0 completes that process by completely removing support for using the WinRM protocol with the remote-exec and file provisioners. Some of the Go libraries that OpenTofu uses for WinRM connection support in provisioners have become unmaintained over time, and so unfortunately we can no longer provide support for this protocol.
If your configuration includes a connection block specifying type = "winrm" then OpenTofu v1.13 will now reject that as an error. We recommend that you migrate to using OpenSSH for Windows before upgrading to OpenTofu v1.13.

Phasing Out Support for 32-bit CPU Architectures

With the OpenTofu v1.12.0 release we preannounced our intention to phase out official releases for 32-bit CPU architectures (386 and arm). OpenTofu v1.13 will be the last series that includes official releases for the affected platforms, and during this series our official releases will produce a warning during tofu init if run on one of the affected platforms.
The forthcoming OpenTofu v1.14 series will not include official packages for these platforms. If you are currently running OpenTofu on a 32-bit CPU architecture then we recommend beginning to plan migration to a 64-bit architecture (e.g. amd64 or arm64) instead.

OpenTofu on macOS requires macOS 13 Ventura

OpenTofu builds for macOS are now supported only on macOS 13 Ventura or later. OpenTofu v1.13 may crash or behave incorrectly on earlier versions of macOS.

Original source

First off, what is a "Symbol Library" and why should I care?

A symbol library is a collection of re-usable language elements that can be loaded into OpenTofu configuration. This includes user defined functions, types, constants, and calls to other symbol libraries.

These libraries are an answer to the long-standing and broad community ask for better and cleaner code re-use. Although OpenTofu uses a declarative configuration language, adding the ability to re-use definitions and logic allows for a whole new level of Don't Repeat Yourself.

What do they look like in practice?

Symbol libraries consist of symbol files (*.sym.hcl) within a directory. Each of these symbol files may contain functions, types, and constants which reference each other.

This somewhat contrived example shows the basics of defining functions, constant values, and types within symbol libraries.

Usage from OpenTofu

Let's assume that the simple example above is located at ./example-lib/example.sym.hcl relative to the current configuration directory.

# Enable the symbol libraries experiment
language {
  experiments = [
    symbol_libraries
  ]
}

# Import the symbols into the current module
symbols "lib" {
  source = "./example-lib"
}

variable "dns" {
  type = symbols::lib::dns_recordset()
}

output "example" {
  value = symbols.lib.example_recordset
}

output "formatted" {
  value = symbols::lib::format_dns_recordset(var.dns)
}

What can't symbol libraries do?

Symbol libraries are static entities that can not directly access any state (resource, data) or provider information directly. Additionally, this means that provider functions can not be used from within symbol libraries.

This is an intentional design feature. You may pass resource values into symbol functions from OpenTofu, but they symbol libraries themselves do not have any concept of resource or data entities.

What is the status of Symbol Libraries?

As this is a whole new HCL based language and fundamental way of working with OpenTofu, we have released this feature as an "Experiment". This means that we are counting on your feedback to stabilize this feature for general use. It is included in the OpenTofu v1.13 release series and can be opted-into by adding

language { experiments = [symbol_libraries] }

to your OpenTofu project configuration. At the time this post is published, it can be tested via the v1.13.0-rc1 release.

If you like so many others have been frustrated by the inability to share your complex logic and types between parts of your project, please give this feature an in-depth look! We have an open discussion on GitHub for gathering feedback and are hoping that enough passionate people like you leave a comment that we can stabilize this feature for v1.14!

Where can I learn more?

This is the first in a series of short blog posts showcasing symbol libraries. We plan to author a few of these posts leading up to the v1.14 release to help spread awareness of the experiment and gather more feedback. The next post in the series will be about building validation functions and leveraging some of the more powerful options therein.

You can also read the RFC where we refined this idea to the point in which it could be built out as an experiment.

Original source

Since early in the life of the OpenTofu project various community members have asked for built-in linting support. Although we always liked the idea of that in principle, we were concerned that the full scope of what people seem to mean by "linting" is a pretty large project of similar size to OpenTofu's core functionality, including support for user-defined lint rules, linting plugins, etc.

At this point the feature request for linting is the most highly-voted issue in our GitHub repository, and so during the v1.13 development period we began investigating what it might look like to integrate linting as a built-in part of the OpenTofu workflow. Of course, that then required us to figure out exactly what functionality that implies, which was more interesting a question than it might first appear!

We're still early in our research and design for these features, but in this article we want to share what we've learned so far and how we're expecting to approach this problem in future releases.

The scope of "linting"

The term "linting" originates from a specific piece of software, literally called "Lint", that was written at Bell Labs to perform static analysis on C source code. This tool would detect and report various situations that are not technically incorrect but are nonetheless likely to cause portability problems or make the code harder to understand by future maintainers.

Today, "linter" tends to describe a wider variety of tools. Some are focused purely on checking for or applying superficial style rules such as which characters are used for indentation and which variable names are allowed. Others perform more detailed static analysis to detect problems such as unreachable code or common mistakes in a specific programming language, but with a fixed ruleset decided by the developers of the tool. In the most general case, the word "linter" instead describes a generic harness for implementing and executing an arbitrary set of separately-developed checks, possibly including checks that are relevant only to a single organization or codebase.

Across all of these the most typical situation is that the "linter" is something separate from the "compiler" or "interpreter", focused only on source-code-based static analysis. A typical linter does not actually execute the program that it's being applied to, and so it cannot react to any dynamic values produced by the program at runtime.

OpenTofu's execution model is unusual in that its "plan" phase already acts as a sort of middle-ground between analysis and execution: it evaluates all of the expressions in the configuration as far as possible while asking providers to predict what they would do with that input, threading the results from one provider to another in an attempt to detect potential problems before making any changes. In that sense OpenTofu's planning phase is already acting in a "linter-like" fashion but using dynamic analysis rather than static analysis.

Lots of organizations have built on this by introducing additional automated checks based on the results from OpenTofu's planning phase. For example, some use Open Policy Agent as a general-purpose policy enforcement tool based on a JSON representation of the OpenTofu plan, and others use Infracost to try to predict the difference in monthly cost that a certain set of changes are likely to cause.

Some teams using OpenTofu's predecessor separately use tflint for static analysis before even running the planning phase. The name of this software suggests that it's focused on linting based on source code, but it works by embedding large parts of Terraform's runtime engine inside it and so even there the distinction between "linting" and "planning" is blurry.

Based on all of this, we've come to believe that pre-plan linting and post-plan policy checks are two parts of the same problem. Instead of defining separate rules for each, OpenTofu could re-check the same set of rules at each phase as more information becomes available.

The OpenTofu project therefore intends to take quite a broad view of what "linting" means: instead of being an entirely separate step run before the main OpenTofu workflow, we'd like to allow operators to provide a single set of rules that get repeatedly checked throughout the OpenTofu workflow: while validating, while planning, and while applying. During each workflow phase, each of the defined checks can either be passing, failing, or have an unknown status that'll be decided in a later phase.

Custom Lint Rules and Linting Plugins

You can get quite far with simple declarative rules evaluated in terms of data already known to OpenTofu. Being able to write those rules in a similar language as OpenTofu modules themselves means that authors can reuse their existing knowledge and can avoid having to install additional interpreters or other tools to use alongside OpenTofu.

However, some checks inevitably require access to external data or to calculations that are too complicated to write ergonomically in a simple configuration language. It's important to offer an "escape hatch" allowing rules to be implemented using general-purpose programming languages.

The good news that OpenTofu already has an existing model for calling into code written in general-purpose languages: provider plugins! We're still evaluating how best to make use of provider plugins as part of defining rulesets. One initial possibility is to allow policy configurations to include data and ephemeral blocks with the same meaning they have in OpenTofu modules. For example, a rule could make use of the results from http in the hashicorp/http provider, or aws_iam_principal_policy_simulation in the hashicorp/aws provider.

One way to think about custom lint and policy rules is as a set of additional postconditions defined in a central place outside of the main configuration. Instead of being associated with individual resources, they'd instead be applied systematically to all resource instances meeting certain criteria. Each rule could be configured either as blocking (raising an error) or non-blocking (raising a warning). They'd otherwise be similar to the various check-related language features you may already be familar with. We plan to design the specifics of this ruleset language in a future RFC, after collecting more use-cases.

Built-in Linting Rules

We understand that much of the community interest in this feature is about defining custom rulesets, but we'd also like to include an evolving set of built-in rules related to OpenTofu's own language features. This is the more traditional definition of "linting", and is an opportunity for OpenTofu to draw attention to usage patterns that are technically valid but nonetheless potentially confusing or harmful, such as:

• Redundant references in depends_on arguments: those with experience in other dependency-graph-based software sometimes misunderstand depends_on as mandatory for declaring all dependencies, or assume it has a stronger meaning than just referring to the same object naturally in a resource configuration.
• Using count instead of enabled for conditional resource instances: those coming from OpenTofu's predecessor may not realize that OpenTofu has explicit support for boolean enablement, and so declarations like count = var.cond ? 1 : 0 are unnecessary unless you expect that you might want to switch to having two ore more instances of the same resource in future.
• Applying the [*] operator to a non-list or non-set value: that usage is allowed as a way to transform a single value that might be null into a tuple of zero or one elements, but there are various situations where that's unlikely to be what the author intended to do, and we'd like to be able to draw attention to those without creating mandatory warning noise even for those who are relying on that behavior intentionally.

OpenTofu v1.13.0 includes some early support for checking a small set of built-in rules, activated by using the experimental -lint=... command line option with either tofu validate, tofu plan, or tofu apply:

tofu plan -lint=all

In the long term we're expecting to have a configuration-file-based approach to configuring linting instead of trying to pack the whole configuration into a command line option, but we've started here just as a way to get some of the internal plumbing in place and begin exposing built-in linting rules to gather feedback about how useful and effective they are. Instead of all you can optionally specify a comma-separated list of specific rules to activate.

The initial set of built-in rules is small but we intend to grow this in later releases:

Rule ID Description core:no-type-variable Detects any input variable that doesn't have a type argument in its declaration. core:count-instead-enabled Detects situations where count is used in a situation where enabled could be used instead. core:unused-variable Detects any input variables that are declared but not used in any expression. core:unused-local Detects any local values that are declared but not used in any expression.

You can learn more about these initial experimental features in Linting. If you try this during the OpenTofu v1.13 series, please tell us about your experience!

Reusable Rulesets

Although some policy rules are inherently specific to a single organization or even to a single configuration, there are certain kinds of policy we've seen defined over and over in different forms across many different organizations' pre-merge linting and post-plan policy rules. For example:

• Detecting firewall rules that allow full access from the public internet.
• Detecting access policies that permit unauthenticated access.
• Detecting objects that are missing tags required by a specific global tagging scheme.

We'd like to allow defining rulesets such that they can be shared in a similar way to how OpenTofu modules are shared. This implies being able to install them from remote sources, and being able to parameterize them with input variables to customize their behavior. It also requires some way for the maintainers of a reusable ruleset to easily test it as they make changes over time, without having to rely on "real" OpenTofu configurations.

We'd Appreciate Your Feedback

So far we've been thinking broadly about the overall problems of pre-merge linting and post-plan policy checks and coming up with some early ideas for how OpenTofu might approach this family of problems in a coherent, holistic way.

Now we need to get more specific. If you're already using either pre-merge linting or post-plan policy checks in your workflow then we'd love to hear more about what specific rules you have in place and what sorts of problems you intend each of those rules to prevent. We'd like these new "linting" features to be able to absorb as many of those use-cases as possible.

We'd also be interested in any specific ideas you have about rules that could potentially be collected into reusable rulesets, for situations that are common across many organizations where it would be helpful to have a robust single implementation that can be maintained collectively for the whole OpenTofu community to benefit.

If you'd be willing to discuss your potential usage, or if you have any general feedback about the overall vision we've discussed in this article, please start a thread in our Linting Feedback discussion!

Original source

SECURITY ADVISORIES:

• When interacting with OCI Distribution registries for module or provider package installation, earlier versions of OpenTofu could incorrectly resend credentials intended for the original origin to the target of an HTTP redirect. (#4422)
• When interacting with an attacker-controlled remote state backend or provider/module registry, tofu init in earlier versions of OpenTofu could potentially cause high CPU usage and/or high memory usage resolving crafted relative URLs in the API responses. (#4472)

Full Changelog: v1.12.5...v1.12.6

Original source

SECURITY ADVISORIES

• When interacting with OCI Distribution registries for module or provider package installation, previous versions of OpenTofu could incorrectly resend credentials intended for the original origin to the target of an HTTP redirect. (#4423)
• When interacting with an attacker-controlled remote state backend or provider/module registry, tofu init in earlier versions of OpenTofu could potentially cause high CPU usage and/or high memory usage resolving crafted relative URLs in the API responses. (#4473)

Note

This is the final patch release planned for the OpenTofu v1.11 series. We recommend upgrading to a newer release series as soon as possible.

Full Changelog: v1.11.13...v1.11.14

Original source

SECURITY ADVISORIES

• Previous releases in the v1.12 series could be affected by several vulnerabilities:
  • The Encrypted Client Hello implementation (which is used by OpenTofu through the go stdlib) would leak the pre-shared key identities during the handshake, allowing a passive network observer who can collect handshakes to de-anonymize the hostname of the server, even when ECH was being used.
  • This is fixed now by (#4363)

BUG FIXES

• Fixed bug where implicit moves and provider address changes would incorrectly cause providers.MovedResourceState to be used in place of providers.UpgradeResourceState (#4375)

Full Changelog: v1.12.4...v1.12.5

Original source

SECURITY ADVISORIES

• Previous releases in the v1.11 series could be affected by several vulnerabilities:
  • The Encrypted Client Hello implementation (which is used by OpenTofu through the go stdlib) would leak the pre-shared key identities during the handshake, allowing a passive network observer who can collect handshakes to de-anonymize the hostname of the server, even when ECH was being used.
  • This is fixed now by (#4363)

BUG FIXES

• Fixed bug where implicit moves and provider address changes would incorrectly cause providers.MovedResourceState to be used in place of providers.UpgradeResourceState (#4375)

Full Changelog: v1.11.12...v1.11.13

Original source

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