by scottmotte on 6/25/24, 2:49 PM with 206 comments
by cimnine on 6/25/24, 6:45 PM
[1] https://blog.diogomonica.com/2017/03/27/why-you-shouldnt-use... [2] https://security.stackexchange.com/questions/197784/is-it-un... [3] https://learn.microsoft.com/en-us/aspnet/core/security/app-s...
by neonate on 6/25/24, 7:19 PM
by sandstrom on 6/25/24, 6:09 PM
It handles task running (wipe local test db, run linting scripts, etc), environment variables and 'virtual environments', as well as replacing stuff like asdf, nvm, pyenv and rbenv.
Still somewhat early days, tasks are experimental. But looks very promising and the stuff I've tried to far (tasks) works really well.
by treflop on 6/25/24, 7:17 PM
If now someone has to read docs to figure out how to configure the app, I’d rather have them read docs for some other safer and more powerful configuration scheme.
by michaelmior on 6/25/24, 4:33 PM
by mplanchard on 6/25/24, 4:06 PM
Sops also integrates easily with AWS and other existing key management solutions, so that you can use your existing IAM controls on keys.
I mentioned in another comment, but I've been using it over five years at two jobs and have found it to be great.
by golergka on 6/25/24, 4:01 PM
by brigadier132 on 6/25/24, 3:55 PM
One reason I can think of is that normally with secrets I actually don't keep any copies of them. I just set them in whatever secret manager my cloud environment uses and never touch them again unless I need to rotate them. Meaning there is no way to accidentally expose them other than by the secret vault being hacked or my environment being hacked.
With this approach if someone gets access to the encryption key all secrets are exposed.
by rrgok on 6/25/24, 4:16 PM
If the vault is password protected, aren't you just adding one more indirection and nothing more? How is that helpful, since now I have to write the vault password in clear-text somewhere such that my application can read the env file from the vault?
by hamasho on 6/25/24, 7:00 PM
[local]
API_KEY=local-key
API_SECRET=local-secret
DB=postgresql://username:password@localhost:5432/database_name
[production]
API_KEY=prod-key
API_SECRET=prod-secret
DB=postgresql://username:password@prod-db:5432/database_name
[staging]
API_KEY=stg-key
API_SECRET=stg-secret
DB=$(production.DB)
On an unrelated note, I always find it a real headache to keep the naming convention of the environments throughout the project. It always ends up like a mixed bag:
* Juggling production/prod, staging/stg, and develop/dev,
* Inconsistent placement of env, e.g. prod-myproject or myproject-stg,
* Skipping env name sometimes, e.g. myproject-bucket for dev S3 bucket but prod-myproject-bucket for prod (though it's okay to emit env name for user facing places like URL),
* Inconsistent resource sharing between envs, e.g. same S3 bucket for local and dev but different DB, or same Kubernetes cluster with different labels for dev/stg but different cluster without a label for prod.
Fix: format
by clord on 6/26/24, 1:14 AM
by wodenokoto on 6/25/24, 4:30 PM
I suppose if you don’t want it to stay after execution i believe you can:
> $(source .env; my command)
by TZubiri on 6/25/24, 8:08 PM
You don't need to encrypt your keys, with what keys are you going to do so? Will you encrypt those?
if someone is in your server you are pwned anyways.
It's ok if you identify yourself as a cybersecurity dude and hold a cybersecurity role and you need to justify your livelihood.
But do it in a way where you don't bother people. It's ok if you bother devs, but then you go on and bother users with 4FA, 5 rule passwords, systems that can't answer subpoenas because you have encrypted your sense of self.
When you are improving security at the expense of every other variable, that's annoying, but when you keep "improving security" at the expense even of security, is the point where people will start ignoring and hiding shit from you
by ComputerGuru on 6/25/24, 4:16 PM
by frithsun on 6/25/24, 9:54 PM
Doubly the case now that env is natively supported by node now.
by stiiv on 6/25/24, 6:14 PM
by boundlessdreamz on 6/25/24, 5:25 PM
In Rails, the entire file is encrypted unlike here where only the secrets are
by dagss on 6/26/24, 5:47 AM
So we can have
FOOPW=pw1
when testing locally, but
FOOPW="{vault1:secret1}"
in production. Env vars are processed simply by running a regex with callback that fetches secrets from vaults. This is quite flexible and has the advantage of being able to inject the secrets in the same place as other configuration, without actually having the secrets in environment variables or git etc (even encrypted)
by ashenke on 6/25/24, 3:32 PM
The URL in `dotenvx` points to https://gitub.com/dotenvx/dotenvx (gitub without the h)
by hermanradtke on 6/25/24, 3:59 PM
by bluelightning2k on 6/25/24, 3:58 PM
It would only break in cases where people's values specifically started with "encrypted:"
by VWWHFSfQ on 6/25/24, 3:49 PM
by drchickensalad on 6/25/24, 11:47 PM
by wodenokoto on 6/27/24, 5:33 AM
Is there a good primer on using vaults? I know how to query and insert into Azure Key Vaults, but architecting around it is unclear to me.
Things that come up for me:
- As (azure) key vaults don't support per secret access rights, where do I store secrets between deployments?
- Should I store connection strings to cloud resources, or just ask the resource for the connection string at deployment time (for Azure, a cloud function pretty much needs a connection string for most basic things. They say they are moving away from this but ...)
- A security warning is send if a key is accessed more then x/times per hour. Does that mean I should pull in the key from vault at deployment? Cache it after first call during runtime?
- Most of our 3rd party vendors gives us 1 and only 1 key. How do I manage that key between development, production and several developers? Right now we mostly forward the e-mail from the vendor with the key ...
by politelemon on 6/26/24, 1:31 PM
by pictur on 6/25/24, 3:53 PM
by jitl on 6/25/24, 3:29 PM
by daralthus on 6/25/24, 3:17 PM
`start: dotenvx run -f .env.local -f .env -- node index.js`
Instead of the -f flag, which now cannot be overriden, one could invoke it with
`DOTENV=.env.staging npm run start`
by sneak on 6/26/24, 8:03 AM
The correct fix for “it’s too easy to accidentally commit .env files with secrets” is to not function (panic/throw) if there isn’t a suitable .gitignore/.dockerignore, not a specialized cryptosystem for .env files. This just creates a different problem.
I simply use an envdir outside of the project and update all my run scripts to use “envdir $CONFIG_PATH <whatever>”. Simpler and safer.
by bradgessler on 6/25/24, 4:31 PM
by nimishk on 6/25/24, 6:53 PM
by tracker1 on 6/25/24, 7:37 PM
I do like to keep a .env.example that you can rename to .env and adjust as desired. I tend to have defaults for running a compose stack locally that close to "just works" as possible.
I doubt I'd ever want to use this in practice.
by PaulHoule on 6/28/24, 6:07 PM
by globular-toast on 6/26/24, 7:07 AM
by the_duke on 6/25/24, 7:14 PM
This is a great tradeoff: easy way to share configuration, easy way to edit non-encrypted config values, reasonable security for the private values.
Doesn't solve key rotation of course, but for small teams this is a great solution.
by skeledrew on 6/26/24, 5:11 AM
by Alifatisk on 6/26/24, 1:50 PM
Can’t I somehow do this in the script itself so “ruby index.rb” is enough? I know I’m only saving a couple of characters in the command line but I’m asking out of curiosity.
by difu_disciple on 6/25/24, 7:32 PM
Does dotenvx support secrets managers?
by blacksoil on 6/26/24, 12:38 AM
The ability to use arbitrary filename for.env is quite nice though!
by kodeninja on 6/26/24, 12:38 AM
by sampli on 6/26/24, 5:02 AM
by ptdorf on 6/25/24, 4:21 PM
by tamimio on 6/25/24, 5:11 PM
And the attackers will be after this file not the .env anymore.
It looks great nonetheless, especially the cross-language feature.
by hooverd on 6/25/24, 7:44 PM
by panzi on 6/26/24, 4:04 AM
A=$B
B=$A
I recently looked into various dotenv implementations just for fun. They're all different. No unified syntax at all. A lot don't do proper parsing either, but just use some regular expressions (like this one), which means they just skip over what doesn't matches. I started to document all the quirks I could find and wrote my own dotenv dialect just for fun. Nobody use it! Anyway, here it is: https://github.com/panzi/punktum
Direct link to the quirks of the JavaScript dotenv implementation: https://github.com/panzi/punktum?tab=readme-ov-file#javascri...
I've also tried to write a parser compatible to JavaScript dotenv (no x) in C++: https://github.com/panzi/cpp-dotenv
by 0xbadcafebee on 6/25/24, 4:42 PM
Environment variables are great for configuration because:
- you can inherit them from a previous application or application(s)
- you can override them in each environment you run your app in
- you can pass them on to other applications
- they are globals that can be loaded by libraries
- they're not hardcoded in the code, so easier to change things without rebuilding, easier to reuse in different ways/environments/configurations
- the OS has primitives for them
- they're simple
- because (by default) when set in application, they are passed on to all future applications/forks/execs
- they are often dumped as part of troubleshooting and aren't considered confidential
- they can often be viewed by external processes/users
- there are restrictions on key names and values and size depending on the platform
- typical "dotenv" solution doesn't necessarily handle things like multi-line strings, has no formal specification
- no types, schemas
- configuration information passed at execution time that can change per environment
- loading or passing secret values
- development environments
- production environments
- an application library ("libconfig") that can load configuration of various types from various sources in various ways
- support for configuration types: key-value, file/blob, integer/float
- support for confidentiality (require specific function to unseal secret values; in programming languages the intent would be you can't just print a stringified version of the variable without an unseal function)
- support for schema (application defines schema, throws exception if value does not match)
- support allowing a configuration to be overloaded by different sources/hierarchies
- support passing a configuration on to other applications
- support tracing, verbose logging
- truly cross-platform and cross-language with one specification, behavior for all
- devs can create a .env file if they want
- devs load 'libconfig' into app, use it to load their configuration values during development. library can have default sources, and even set env vars or an object internally, so no code needs to be written to use it
- in production, same code causes libconfig to look at cloud-native and other sources for configuration
- when debugging, secret confidentiality is maintained, tracing communicates sources of configuration, what was loaded, from where, etcby daralthus on 6/25/24, 9:15 PM
This is the only goal and this tool archives it. In the simplest way. While keeping you as secure as you were before, manually setting envs on heroku, railway, aws, jenkins etc.
GitOps FTW
by swedonym on 6/25/24, 8:41 PM
by Aeolun on 6/26/24, 12:24 AM
by rednafi on 6/25/24, 10:29 PM
by nunez on 6/25/24, 7:56 PM
I wonder if dotenvx ensures that .env is in .gitignore and yells loudly if it is not.
I encrypt my dotenvs with gpg, but that's hella esoteric and everyone shouldn't be forced to do that.
by yashbindal on 6/26/24, 11:39 AM
by jbverschoor on 6/26/24, 9:52 AM
by cyberax on 6/25/24, 5:51 PM
For this kind of encryption to work, you need to supply the decryption key from some outside system (e.g. via env vars, AWS SSM, etc.). And if it can supply the key, then why not just use it for other important secrets directly?
by boxed on 6/25/24, 3:17 PM
by bdcravens on 6/25/24, 3:14 PM
by throwaway240403 on 6/25/24, 3:23 PM