[Nullabillity]

"Made for sharing", but suggests depending on 1Password?

It also seems.. irresponsible to claim that @sensitive values "will be always be redacted in CLI output", when the whole point of something like Varlock is to configure some external application that it doesn't control.

And what does "AI-friendly" mean here anyway... beyond, I suppose, varlock being AI slop itself.[0]

[0]: https://github.com/dmno-dev/varlock/tree/514917f4228d49d4404...

[theozero]

We say "made for sharing" because .env.schema replaces .env.example which always drifts from reality - and often requires insecurely sharing secrets manually.

Even if not setting values within your files, you can rely entirely on env vars in the platform where the code runs and still benefit from validation provided by varlock.

Right now we give 1Password as an example, but you can use any provider that has a CLI. We are also working on a plugin system that should make it easier to integrate with any provider.

As for redaction - that note is about how we redact your secrets from _our_ CLI output. However we also provide tools to redact within your application. Right now this works only in JavaScript, by patching global console methods. We will also hook into stdout for varlock run, similar to what the 1Password cli does.

The leak detection is much more interesting - especially in hybrid client/server frameworks, where you can easily shoot yourself in the foot.

By removing plaintext secrets from env files, we totally remove the risk of them leaking via AI code assistants, which I guarantee is happening millions of times a day right now. Also the schema itself and autogenerated types give AI much more context about your env.

[halfcat]

I don’t know about varlock, but 1Password’s `op` CLI tool seems to hook the STDOUT pipe and find/replace any instances of the secrets with “concealed by 1Password”. It works even if I drop into a REPL and try every way I can think of to print it out to the console.

So it would seem, on that front, that 1Password is doing the heavy lifting.

Using 1Password in this way has proven way better than storing .env files in plain text on dev machines, where the .env files get picked up if a company does backups, or someone stores a repo in their Dropbox folder, file gets flagged as potential malware and uploaded somewhere for further analysis, etc.

[theozero]

Exactly. We will do that to stdout - and can patch JS itself too.

The goal here is to just make it dead simple to do the right thing with minimal effort. Get secrets out of plaintext, avoid the need to send them around insecurely, and help make sure you don't shoot yourself in the foot, which is surprisingly easy to do in hybrid server/client frameworks like Next.js.

Can you set up validations, syncing with various backends, and these protections all of this yourself by wiring together a bunch of tools with custom code? Of course... But here's one that will do it all with minimal effort.