Encryption of secrets stored in state and or support for a would be an excellent first fork feature to pull ahead. Maybe something that supports backends like AWS KMS (for encryption) or AWS Secret Manager (for storing/retrieving ) secrets.

Stringing together resources to pull from a secrets manager and still having the secrets stored plainly in state is enormously frustrating. We aren’t all living in a nirvana of fast rotating out of band secrets.

This is actually a feature I'd love OpenTF to have and am quite passionate about, personally. My plan is to submit it once we have the RFC process in place.

Disclaimer: Work at Spacelift, and currently temporary Technical Lead of the OpenTF Project, until it's committee-steered.

> > Maybe something that supports backends like AWS KMS (for encryption) or AWS Secret Manager (for storing/retrieving ) secrets.

> This is actually a feature I'd love OpenTF to have and am quite passionate about, personally

You're probably already aware, but SOPS¹ kinda fits the bill for integration here perfectly.

It supports local secrets as well as encryption via keys stored with all the big cloud providers, and it's already battle-tested as it is used heavily at Mozilla (it comes from there).

Additionally, like OpenTF, SOPS is maintained independently of any single corporation, written in Go, and distributed under the MPL-2.0 license. On its face, it seems like a match made in heaven.

SOPS is a great tool and could be a pretty killer starting point for this stuff!

--

1: https://github.com/getsops/sops