91–96 of 96 posts
Earlier quoted context omitted.
Also annoyed that the title has > and here's how to do it better And then basically just says go use a vendor solution. Cool.
Yeah, equally disappointed. I know vendors secret stores are better. But what do I do that isn’t vendor-locked and is remotely as simple as environment variables?
use pass.
Earlier quoted context omitted.
TIL Nike (the shoe company) has a surprisingly intense OSS presence. https://github.com/orgs/Nike-Inc/repositories
Oh you work in tech and never heard of the strong influence of the FAANG (Fila, Adidas, ASICS, Nike, Gucci)?
Earlier quoted context omitted.
I'm not sure if I understood something wrong, but .env files are for development, not production. It never crossed my mind to use .env files for production deployments, but skimming the blog post, it seems like people do ship a .env file to their production environment?
Encrypting dotenv files is a thing, I would even say it has become popular! https://dotenvx.com https://github.com/getsops/sops
Just make sure that you gitignore the plain-text dotenv. That's the hard part (on a team)
This article has about as much insight as I would expect from a "nodejs-security.com" article. This article spends a good deal of time conflating two things: putting stuff in .env and using environment variables. The application-parsed .env file is one of the most poorly thought-through ideas that has taken hold in modern application development. It takes something you can do in literally a couple lines of shell (as…
As middle ground for small scripts I like implementations like the one from 1Password: The environment variables contain the path to the secret: export DB_PASSWORD="op://app-prod/db/password" Calling the script with `op run scriptname` replaces the secret path with the actual secret after authentication during runtime. This way you can commit the file but people still can use their own passwords locally without savin…
$ export DB_PASSWORD=foo
$ sh
sh-5.1$ cat /proc/self/environ
SHELL=/bin/mksh DB_PASSWORD=fooIn what world does this work? $ curl http://your-website.com/public/../../../../proc/12345/environ If your server is serving up your whole filesystem, you likely have a lot of big problems.
You'd be scared how often this works (Though not in the exact method you described). It might not even be a path traversal vulnerability [0] that lets you read files, it could be a shell injection [1] that allows you to `cat` the file.
[0] https://en.wikipedia.org/wiki/Directory_traversal_attack
[1] https://en.wikipedia.org/wiki/Code_injection#Shell_injection
Earlier quoted context omitted.
TIL Nike (the shoe company) has a surprisingly intense OSS presence. https://github.com/orgs/Nike-Inc/repositories
> Nike (the shoe company) as opposed to Nike, the Ancient Greek goddess of Victory, who contributes essentially nothing back to the OSS community