Feature/enable fips compliance

[topperge]

Resolves #2026

Description

This PR implements FIPS 140-3 compliant mode for OpenTofu using Go 1.24+'s native FIPS support. When enabled via the GODEBUG=fips140=on environment variable, OpenTofu will use only FIPS-validated cryptographic modules for all operations.

Key Changes

• FIPS Detection: Uses crypto/fips140.Enabled() to detect when FIPS mode is active
• GPG Validation Handling: Automatically skips GPG signature validation in FIPS mode (the ProtonMail/go-crypto/openpgp library is not FIPS-compliant) with a logged warning
• Security Model: In FIPS mode, provider integrity relies on FIPS-validated TLS connections and FIPS-approved checksum verification
• Documentation: Added comprehensive docs explaining how to enable FIPS mode, implications, and limitations
• Testing: Updated e2e tests to handle FIPS mode gracefully

What Works in FIPS Mode

• All TLS connections (provider plugins via mTLS, backend storage, registry access)
• State encryption (AES-GCM via FIPS-validated modules)
• Checksum verification (SHA-256 via FIPS-approved algorithms)
• Random number generation (FIPS-approved DRBG)

Known Limitations

• GPG signature validation is automatically skipped (library incompatibility)
• Security relies on FIPS-validated TLS + checksums instead

Files Changed

• internal/getproviders/package_authentication.go: Skip GPG validation when FIPS is enabled
• internal/command/meta_providers.go: Comment explaining FIPS compatibility with AutoMTLS
• internal/command/e2etest/*_test.go: Updated tests to handle FIPS mode
• docs/fips_support.md: Technical documentation
• docs/usage/fips.md: User-facing documentation
• CHANGELOG.md: Feature announcement

Checklist

• I have read the contribution guide.
• I have not used an AI coding assistant to create this PR.
• I have written all code in this PR myself OR I have marked all code I have not written myself (including modified code, e.g. copied from other places and then modified) with a comment indicating where it came from.
• I (and other contributors to this PR) have not looked at the Terraform source code while implementing this PR.

Go checklist

• I have run golangci-lint on my change and receive no errors relevant to my code.
• I have run existing tests to ensure my code doesn't break anything.
• I have added tests for all relevant use cases of my code, and those tests are passing.
• I have only exported functions, variables and structs that should be used from other packages.
• I have added meaningful comments to all exported functions, variables, and structs.

Website/documentation checklist

• I have locally started the website as described here and checked my changes.

[github-actions]

Reminder for the PR assignee: If this is a user-visible change, please update the changelog as part of the PR.

[apparentlymart]

Thanks for working on this, @topperge!

#2026 was labelled as "need-rfc" because we felt that it needed more exploration and decision making before we could move forward with implementation.

Your writeup here does include some answers to questions that such an RFC would presumably cover, but for something security/compliance-sensitive like this I think we should go through the full RFC process so that we have a written record not only of what we decided but why we made those decisions and what we expect the implications of those decisions to be, so that we can make sure to make compatible tradeoffs in future work and so that anyone who might rely on this can know what we're assuming about their requirements and determine whether this does meet their requirements.

In particular (though this is not the only thing that I'd want to explore more in an RFC) I think we need to justify why it's an appropriate tradeoff to implicitly disable the key verification for providers, since having fewer checks when working in a mode that's associated with well-defined security controls seems counter-intuitive.

I note also that what we approved (provisionally, pending RFC) in #2026 was not to support two different usage modes for OpenTofu, but instead to compile OpenTofu in a way that forces this mode on for all users, so that we don't effectively double the number of supported configurations for using OpenTofu. We'd expected that -- assuming we can answer all of the associated design questions in a satisfactory way -- we'd add godebug fips140=on to our go.mod and thus produce OpenTofu releases that are FIPS-compliant by default, rather than only as an opt-in¹.

With all of that said: I think we should work through the RFC process on this before considering any specific implementation. Would you be interested in working on such an RFC? The project maintainers could provide some more context on the original issue about what sort of design questions we'd want such an RFC to answer, if that would help quantify the likely work involved in that.

Thanks again!

Footnotes

1. I must admit that I'm surprised to see GODEBUG working as a runtime-handled environment variable as in your proposed documentation, because from the upstream documentation I'd understood fips140=on as a request to the Go toolchain (at compile time) to link in a specific cryptographic module, and so I wouldn't have expected that cryptographic module to be included at all when that setting wasn't present at compile time.

   Can you share a link to the documentation you referred to that told you that was supported? I'd like to understand more about how it works and what the implications of that strategy are. 🤔 ↩

[apparentlymart]

The docs directory in this repository is reserved only for development documentation whose audience is contributors to the OpenTofu codebase.

If we do decide to ship something that requires end-user-configuration (as opposed to being force-enabled for all users) then we'd want to document it somewhere under the website/docs/cli directory so that it would appear in the end-user-oriented documentation on our website.

[apparentlymart]

To try to answer my own question about the runtime handling of GODEBUG I went to dig around in the docs again, and found FIPS 140-3 Compliance which has the following to say about it:

The run-time fips140 GODEBUG option controls whether the Go Cryptographic Module operates in FIPS 140-3 mode. It defaults to off. It can’t be changed after the program has started.

(Emphasis mine)

So indeed it does seem like it's possible to turn this on at runtime despite the fact that the OpenTofu project has not committed to support it.

The GOFIPS140 environment variable is a compile-time setting, but it decides which version of the cryptographic module to use rather than whether the cryptographic module is linked in to the executable at all.

Given all of that, it seems like we (the maintainers on behalf of the project) need to make a decision about whether and how we are going to support running tofu in an environment where GODEBUG is set and specifies a fips140 setting other than off. I'm going to post a comment on the original issue about that, since that's a better place to have this discussion where it's more visible to others who are following the issue.

Thanks again for working on this! I hope we can find a reasonable compromise.

[cam72cam]

Given our decision in #2026, we are closing this PR.

Thank you for your patience @topperge.