Terraform signs Windows executables and repairs credential-file replacement

A successful authentication exchange is only part of logging a command-line tool into a service. The resulting credential must also reach durable local storage. Terraform 0.12.24 repairs that last step on Windows, alongside a distribution change that identifies HashiCorp as the publisher of the Windows executable.

The March 19 release announces signed 32-bit and 64-bit Windows executables. Its stated user-visible result is the removal of the unknown-publisher warning when running the software. The same release fixes Windows login and a panic in the registry client when its server cannot be reached.

These changes concern the parts of Terraform surrounding configuration evaluation. I regard those parts as essential to a useful infrastructure abstraction. A configuration language depends on a CLI that can be installed, acquire credentials and explain a failed dependency request without introducing another failure.

Closing the file before replacement

The login fix in pull request 24397 changes the order of operations in the local credentials writer. The existing implementation wrote a temporary file and attempted to rename it over the credentials file while that temporary file was still open. It deferred closing the handle until the function returned.

The patch moves the close immediately after the write. Whether the write succeeds or fails, the handle is closed before subsequent processing. A failed write still produces its own diagnostic. A successful write can proceed to the rename without retaining the open temporary-file handle.

That order explains why a release note naming Windows login can correspond to a small change in general credentials code. The token-acquisition process does not need a Windows-specific replacement. The operation failing at the end of the process concerns the file that stores its result.

The patch also moves the permission operation. Previously, the writer applied mode 0600 to the open temporary file. The revised implementation applies that mode to the destination filename after replacement. The accompanying comment says that owner-only readability may not be effective on every platform, but should work on Unix-like systems.

Those details limit the claims that can be made about the fix. It changes handle lifetime and permission-setting order. It does not announce a new encrypted credentials format or a different authentication protocol. The correctness issue is the sequence used to persist the token already obtained.

Temporary files need explicit failure handling

The implementation retains cleanup for a temporary file that has not been moved. A flag records whether replacement completed, and deferred cleanup attempts to remove the temporary name when necessary. Closing the file early therefore does not discard the separate responsibility to remove an abandoned temporary file.

This is a useful distinction in code review. Handle cleanup and temporary-path cleanup are different operations. Deferring both until function return can look tidy, but the handle may need to be released before another filesystem operation can succeed. The patch makes that ordering visible at the write site.

The destination permission change can also fail after the replacement. The implementation returns a specific error if it cannot set the mode. That means the persistence operation has several observable stages. A single success message must wait until the required stages finish, even though some earlier work may already have changed the filesystem.

I find this more informative than describing the patch simply as improved Windows compatibility. It identifies the assumption in the old code, which was that an open temporary file could remain open through replacement. The revised sequence expresses the dependency between closing that handle and continuing the operation.

Signing changes the installation experience

The versioned changelog places Windows executable signing in its own release note. HashiCorp says the official executables carry its certificate. This concerns recognition of the executable's publisher, while the login patch concerns behavior after the executable starts.

The distinction matters for deployment instructions. Signing does not imply a change to Terraform configuration syntax, provider selection or the credentials layout. Its practical benefit is at the point where Windows evaluates the downloaded program and presents publisher information to the user.

The changelog also records an earlier signing and notarization change for macOS in 0.12.18. That entry describes a different platform's execution checks. The Windows announcement belongs to the same operational category, making official binaries usable within the platform's software-distribution expectations.

A network error should remain a network error

The registry fix in pull request 24411 repairs another assumption about a resource that may not exist. The old retry error handler read the response status code while constructing an error message. A network failure can leave the response absent.

The revised code checks for a response before reading its status. When there is no response but there is an error, it includes the error instead. It retains the attempt count when retries occurred, and avoids describing a single attempt as repeated attempts.

The new regression test shuts down a test server before requesting module versions. It expects an error and no response, then checks the resulting message. That makes the failure mode concrete without requiring an unavailable external registry.

Together, the fixes improve two failure-sensitive boundaries in the CLI. Credentials reach their destination after their file handle closes, and registry failures produce diagnostics even when a server never returns an HTTP response. Both changes let the original operation determine the result instead of an assumption in its cleanup or reporting code.