#4578·opentofu

[v1.13] Add warning when `base64gzip` or `base64gunzip` usage is detected in resource arguments

Author: yotttaCreated Sep 16, 2026Updated Sep 16, 2026
Labelsenhancementquestionpending-decision

In Go 1.27, a minor change was introduced to the compress/flate package which affects the output bytes when gzip is used. In the context of OpenTofu, the functionality of this Go package is used in the implementation of the base64gzip and base64gunzip resulting in a different final output bytes of these functions.

OpenTofu v1.13 is built against Go 1.27 meaning that the output of these core functions will be different compared with the output in OpenTofu pre v1.13.

bash
%> tofu1.12.6 -version
OpenTofu v1.12.6
on darwin_arm64

%> echo 'base64gzip("hello world")' | tofu1.12.6 console
"H4sIAAAAAAAA/8pIzcnJVyjPL8pJAQAAAP//AQAA//+FEUoNCwAAAA=="
bash
%> tofu1.13.0 -version
OpenTofu v1.13.0-beta1
on darwin_arm64

%> echo 'base64gzip("hello world")' | tofu1.13.0 console
"H4sIAAAAAAAA/wALAPT/aGVsbG8gd29ybGQAAAD//wMAhRFKDQsAAAA="

The concern with this is that the usage of these functions could be used in resource arguments that might trigger a replacement of resource by solely upgrading from an OpenTofu pre v1.13 version to OpenTofu v1.13. One such example, is the usage of these functions on the aws_instance resource user_data argument. By upgrading to OpenTofu v1.13, it might generate a replacement of such resource.

Besides multiple communication solutions already discussed and agreed by the maintainers, we would like to also consider adding a temporary warning diagnostic when the usage of base64gzip and/or base64gunzip in resource arguments. This warning will live through the OpenTofu v1.13 series and will be removed starting with v1.14 one.

The proposed solution is to use the go-cty marks functionality, by marking the values generated by the targeted core functions and later generate the warning if the marks are found on resource arguments values. The warning should be generated once per run and OpenTofu should allow the full suppression of it by using a hidden temporary environment variable (eg: TF_GZIP_COMPAT_WARN=false).

This issue is meant to capture the opinions on the proposed approach and in the end should contain the final decision with a possible implementation of the proposal, in case the decision is to go forward with adding such a warning.