3 ms·
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 solutio
by 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 agoSince it's Ruby, wouldn't any supply chain hacks have access to the source code, and thus the decryption key?
- itake 5y agoTrue, 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 agoYes, 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.