3 ms·

> - On a user device, secrets are periodically removed from RAM if they haven't been accessed recently. I looked at the ruby sdk code and it doesn't periodical

by itake 5y ago

> - On a user device, secrets are periodically removed from RAM if they haven't been accessed recently. I looked at the ruby sdk code and it doesn't periodically remove them from RAM. Storing the ENVs in the `ENV` object makes me nervous, because its an easy target for supply attacks to dump the `ENV` to logs / remote servers.

danenania 5y ago
You're right--another distinction is needed here. For a human user using EnvKey, the EnvKey 'core-process' will run on their computer. Both the EnvKey UI and the CLI talk to this core process to fetch/display data or make updates. This is the process that will periodically evict secrets from RAM if they aren't used. When loading a single environment via an ENVKEY access key, you're correct that there is no RAM eviction (in many cases this could break an app, unless it was designed to handle it). If you don't want to use ENV/environment variables, you could also output your environment to a file and then pull it into your app and parse it (you can easily export to json, yaml, dotenv, or pam format): $ es --dot-env > .env $ es --json > .env.json $ es --yaml > .env.yaml $ es --pam > /etc/environment
- itake 5y ago
  Those cmds write the variables unencrypted to disk? Looking at the ruby sdk, I don't see any decryption libraries being used. I'd imagine a more secure solution would be to give the sdk the decryption key when the variables need to be decrypted, they are only decrypted by the process in RAM. Since its ruby, and everything has access to everything in the process, it might make more sense to key management to exist in another process (thus limiting what access simple supply chain attacks have access to).
  - nicoburns 5y ago
    Since it's Ruby, wouldn't any supply chain hacks have access to the source code, and thus the decryption key?
    - itake 5y ago
      True, but if the attack isn't targeted to the application, the attacker may naively just dump the `ENV` object instead of trying to it in the gem's memory space.
  - danenania 5y ago
    Yes, those commands write the variables to a file, though you could also make a system call instead from within your app if you didn't want them in a file or environment variables. The language SDKs (including ruby) wrap the envkey-source binary, which is where all the decryption and verification logic lives: https://docs-v2.envkey.com/docs/envkey-source https://docs-v2.envkey.com/docs/envkey-source There is an -m/--mem-cache flag that you can pass to envkey-source that makes it work just as you're describing. It keeps the variables in RAM and listens for updates, keeping them all up-to-date.

by itake 5y ago

danenania 5y ago

You're right--another distinction is needed here. For a human user using EnvKey, the EnvKey 'core-process' will run on their computer. Both the EnvKey UI and the CLI talk to this core process to fetch/display data or make updates. This is the process that will periodically evict secrets from RAM if they aren't used. When loading a single environment via an ENVKEY access key, you're correct that there is no RAM eviction (in many cases this could break an app, unless it was designed to handle it). If you don't want to use ENV/environment variables, you could also output your environment to a file and then pull it into your app and parse it (you can easily export to json, yaml, dotenv, or pam format): $ es --dot-env > .env $ es --json > .env.json $ es --yaml > .env.yaml $ es --pam > /etc/environment

itake 5y ago
Those cmds write the variables unencrypted to disk? Looking at the ruby sdk, I don't see any decryption libraries being used. I'd imagine a more secure solution would be to give the sdk the decryption key when the variables need to be decrypted, they are only decrypted by the process in RAM. Since its ruby, and everything has access to everything in the process, it might make more sense to key management to exist in another process (thus limiting what access simple supply chain attacks have access to).
- nicoburns 5y ago
  Since it's Ruby, wouldn't any supply chain hacks have access to the source code, and thus the decryption key?
  - itake 5y ago
    True, but if the attack isn't targeted to the application, the attacker may naively just dump the `ENV` object instead of trying to it in the gem's memory space.
- danenania 5y ago
  Yes, those commands write the variables to a file, though you could also make a system call instead from within your app if you didn't want them in a file or environment variables. The language SDKs (including ruby) wrap the envkey-source binary, which is where all the decryption and verification logic lives: https://docs-v2.envkey.com/docs/envkey-source https://docs-v2.envkey.com/docs/envkey-source There is an -m/--mem-cache flag that you can pass to envkey-source that makes it work just as you're describing. It keeps the variables in RAM and listens for updates, keeping them all up-to-date.