Docs: full `.sops.yaml` spec & dotenv examples / troubleshooting

[tj-smith47]

I've seen a number of issues over the years about problems with dotenv files not encrypting properly. Some were user error, but some I can reproduce. I'm trying to take a repo containing unencrypted files using file extensions .yml, .json, .env, and .conf, and am passing them through sops to an encrypted variant of the repo (so I'm not using the in place flag, nor am I renaming any files / adding .enc). With the exception of .env, all of these are properly encrypted.

As an example, using a file named project/base/project.env containing 4 lines of KEY=val and passing it through sops -e [unencrypted_file] > [encrypted_file] results in 4 unencrypted lines atop the file. I've also tried many different combinations of --input-type [dotenv|binary] and/or --output-type [dotenv|binary]. The closest I've gotten is that it combines all lines in a single data key with \n joining the lines on decryption.

I imagine the reason I'm struggling with this (and many others have in the past as well) is due to the lack of explicit examples / FAQ around dotenv files, in combination with a lack of a full .sops.yaml spec outlining all supported values. Initially I had set a creation rule regex of ^(string|stringData)$, but removing that still results in gitleaks flagging the unencrypted values.

I (and I'm sure many others) would immensely appreciate a dedicated section around the nuances of working with dotenvs, what to check when they're not encrypted properly, and a full .sops.yaml spec being published. In the meantime however, if you're familiar with the cause of my issue and have a solution you could recommend, that would be very helpful.

[felixfontein]

As an example, using a file named project/base/project.env containing 4 lines of KEY=val and passing it through sops -e [unencrypted_file] > [encrypted_file] results in 4 unencrypted lines atop the file.

Can you provide an explicit example?

[tj-smith47]

@felixfontein I was able to get it working by instead using unencrypted_regex: ^(apiVersion|kind|metadata|type)$ and re-encrypting everything. I had to stumble upon more examples of these configuration keys being used in the wild to ever think to use this, but it works. I'm not able to give you an explicit example as this is a work repository, but there's nothing special about the ENV's, they look like any ENV file and contain only alphanumeric values.

While I know this very well may be a separate topic, it does align with the broader theme of "documentation improvements", and I can't say for certain there's nothing in my configuration that is preventing this from working - I cannot for the life of me get CLI diffing to work. The section of the docs makes it seem so simple, but appears to either be incomplete, or contain som assumptions. I've run the steps verbatim - is there anything implied you can think of that I also need to do to get diffing in the terminal to work besides what's shown in the readme? I created a test yaml file, staged it, changed it, and diffed it, and I see a sops diff rather than a diff of what I changed. If you need any more info I'm happy to provide it.