[aszen]

I wonder why we are even storing secrets in .env files in plain text

[makoto12]

This wouldn't have made the front page if it was: "How to not store your secrets in plain text"

[patapong]

I would also prefer not doing this. Does anyone know of any lightweight, cross platform alternatives?

[geoffeg]

I use sops and age, originally loosely based on this article: https://devops.datenkollektiv.de/using-sops-with-age-and-git...

I originally set up the git filters, but later disabled them.

[phrotoma]

Perhaps I'm off base here but it seems like the goal is:

1. allow an agent to run wild in some kind of isolated environment, giving the "tight loop" coding agent experience so you don't have to approve everything it does.

2. let it execute the code it's creating using some credentials to access an API or a server or whatever, without allowing it to exfil those creds.

If 1 is working correctly I don't see how 2 could be possible. Maybe there's some fancy homomorphic encryption / TEE magic to achieve this but like ... if the process under development has access to the creds, and the agent has unfettered access to the development environment, it is not obvious to me how both of these goals could be met simultaneously.

Very interested in being wrong about this. Please correct me!

[eddd-ddde]

https://www.passwordstore.org/

You can easily script it to decode passwords on demand.

[WhyNotHugo]

If your .env file is being sourced by something like direnv, you can have it read secrets from the secret storage service and export them as env vars.

If you bind-mount the directory, the sandbox can see the commands, but executing them won’t work since it can’t access the secret service.

[aszen]

https://devenv.sh/integrations/secretspec/

[johnisgood]

I would like an answer, too.