how can it upload a .env when its there in .gitignore? even if you go and remove the entry of .env from .gitignore, it doesn't start getting tracked right?
but yeah there should be some commit hook that rejects a commit like this for obvious non starters like a .env or credentials.yaml or something (UNLESS the dev explicitly goes and toggles that setting to be off)
This is not about Git, this is about their `.env` contents being sent to an external server for tab complete, even if that file is explicitly marked as "do not use the AI here".
This is the biggest concern I've with Cursor. In fact, even though I use Cursor often, I won't use it on any repository with secrets or personal information. (Based on this news, I'm happy I went that route.)
If the Cursor team is reading, I'd recommend that you give real-time visibility into exactly what's indexed and uploaded and have more rigorous testing and documented guarantees around .cursorignore. That would go a long way toward making people like myself feel better about the product.
Almost every application out there supports environment variables for configuration, and every language supports reading data from the environment.
dotenvs are a clean and lightweight way of using this pattern that works regardless of tech stack. If the language doesn't have a library for loading dotenvs, you can usually write a simple library for it with a few lines of code.
In Golang-land, this is much easier than having to boilerplate your way through a Config interface with a Config struct for defining the YAML schema, though I suppose this is a non-issue with LLMs now.
Ensuring that plain-text dotenvs aren't in gitignore and that encrypted dotenvs are can be enforced with client-side Git hooks, which are painless to set up, in my opinion.
That said, I mostly use sops with PGP these days. YAML is more expressive than dotenv, though sops works well with dotenvs. I would recommend sops + Vault for enterprise scenarios.
> Almost every application out there supports environment variables for configuration
It didn't used to be that way, surprisingly. Most configuration was done via files using INI. Then people started using JSON, and now YAML -- if they have a configuration file at all. Containers pretty much required using environment for configuration because it was the only way to "inject" configuration before we got volumes and fancy stuff like secrets.
That doesn't make it any less of a hack instead of a proper configuration format.
Tools like direnv gets .env files out of repo paths and improves things a lot. You can integrate secrets management in code, but with that there's still no getting away with the assumption that some kind of auth mechanism exists in your env
Readit News
but yeah there should be some commit hook that rejects a commit like this for obvious non starters like a .env or credentials.yaml or something (UNLESS the dev explicitly goes and toggles that setting to be off)
Regardless of whether it actually makes a commit with the secret, it's still being leaked.
If the Cursor team is reading, I'd recommend that you give real-time visibility into exactly what's indexed and uploaded and have more rigorous testing and documented guarantees around .cursorignore. That would go a long way toward making people like myself feel better about the product.
Almost every application out there supports environment variables for configuration, and every language supports reading data from the environment.
dotenvs are a clean and lightweight way of using this pattern that works regardless of tech stack. If the language doesn't have a library for loading dotenvs, you can usually write a simple library for it with a few lines of code.
In Golang-land, this is much easier than having to boilerplate your way through a Config interface with a Config struct for defining the YAML schema, though I suppose this is a non-issue with LLMs now.
Ensuring that plain-text dotenvs aren't in gitignore and that encrypted dotenvs are can be enforced with client-side Git hooks, which are painless to set up, in my opinion.
That said, I mostly use sops with PGP these days. YAML is more expressive than dotenv, though sops works well with dotenvs. I would recommend sops + Vault for enterprise scenarios.
It didn't used to be that way, surprisingly. Most configuration was done via files using INI. Then people started using JSON, and now YAML -- if they have a configuration file at all. Containers pretty much required using environment for configuration because it was the only way to "inject" configuration before we got volumes and fancy stuff like secrets.
That doesn't make it any less of a hack instead of a proper configuration format.
Deleted Comment