> you could look into using something like “env” to spawn the process with a reduced environment
Can you elaborate/show an example?
I agree in general to limit sensitive data stored in env vars, but often it's not feasible. One might have e.g. AWS keys loaded when using Terraform. The problem in this particular case is that Cursor is not selective in what env vars are loaded, it serializes _everything_. That seems like an odd choice to me.
> The problem in this particular case is that Cursor is not selective in what env vars are loaded, it serializes _everything_. That seems like an odd choice to me.
If you want to stop it having access to your secrets, that is done by not providing them, not by hoping that it won't access the secrets that you give it. The focus on what Cursor is doing after it already has access that you didn't mean to give it, instead of on what you are doing to provide that access to it, seems the wrong way around.
The basic pattern is instead of launching your binary directly, you launch it using something like /usr/bin/env -i PATH=/bin:/usr/sbin TMPDIR=/var/tmp/thisprocess/tmpdir SOMEOTHER_ENV_VAR1=foo SOMEOTHER_ENV_VAR2=bar mybinary args
ie you whitelist just the env vars you know your process needs to operate and set a specific path. This prevents a lot of problems caused by weird LD_LIBRARY_PATH exploits, and also more prosaically prevents things like api keys from being passed into processes that don't need them and ending up in debug messages, logfiles etc. It's also good when you're root to do this so you don't accidentally start long-running processes using your user environment which is probably full of stuff that while not actively harmful, the process doesn't need and could cause problems...
process id: 54279
process args: -p "<some id>" + JSON. stringify(process.env) + "<some id>"
process path: /Applications/Cursor.app
The alert showed up right after I installed the app and clicked on the Cursor icon [1]. I understand that processes can access the entire environment by default (which was always a bit too "open"/strange for my taste, but I get the reason) but then I don't understand why you need to use `JSON. stringify(process.env)`
[0] <some id> was some 12 character hex string
[1] Note that this was like a month ago; I have a cold, so finally have time to catch up on such questions
I know nothing about how Cursor is implemented, so this may be wildly off base, but...
Perhaps it is written using some kind of JavaScript framework that doesn't allow access to the process environment by default, but this lets them work around that to access the environment like a native app?
One reason you'd want an IDE to have access to your environment is to enable any tools/compilers/whatever you launch from the IDE to inherit the environment (say, to access SSH_AGENT_SOCK, or whatever).
Ok, this sounds like a plausible direction — thanks!
It seems that Cursor is using Electron. I don't know about its internals (tried it a couple of times years ago), but after a quick look at the docs I've found this: https://www.electronjs.org/docs/latest/api/utility-process#u...
which is a section describing `utilityProcess.fork(modulePath[, args][, options])`:
env Object (optional) - Environment key-value pairs. Default is process.env.
I don't get why some unique-looking prefix/suffix would be needed there, though.
Why does that seem like an odd choice? An experienced developer knows that making a list of which vars are relevant and only serializing those means extra work in the future to upkeep the list. Seems odder to pick just the one you want in that instant.
Can you elaborate/show an example?
I agree in general to limit sensitive data stored in env vars, but often it's not feasible. One might have e.g. AWS keys loaded when using Terraform. The problem in this particular case is that Cursor is not selective in what env vars are loaded, it serializes _everything_. That seems like an odd choice to me.