Web Dev full-stack [LAMP] since 2005, but much heavier on the JS stuff these days.
Jack of all Stacks, Master of some.
Always looking to learn new things. Always glad to help out, just ask.
Location
Atlanta, GA
Education
B.S. in Biochemistry 2004, M.S. in Computer Information Systems 2007
every single security measure has its weaknesses, going by the original post here, using .ENV files is a thousand times simpler than what he proposes and maybe slightly less secure, but a thousand times easier to repair in case of an attack than the original post's process. That's all i was getting at and this thing blew up lol
A software engineer that specializes in serverless microservices. I love creating helpful content about programming and reverse-engineering.
I am employed at Google; all opinions are my own.
At the end of the day, your dotenv-vault is functioning like a config server.
Yes, you are correct.
I think we are toward the same end here. You recognize the problem we see as well.
But throwing out the .env file will be a mistake. They need to work together. The config server should layer on top of .env files.
Currently, all implementations of config servers require you to learn a new proprietary system, rewrite code, and get locked into it. Plus, there is training on the new system for your dev team.
That's why we think all config servers should be built on top of the defacto .env file standard. This way, you get all the security benefits of .env files PLUS solve the insecure sharing and config issues.
That is what we are doing with dotenv-vault.
This has the added benefit that you could choose to leave dotenv-vault, and everything would still work. Or you could switch to a different provider that syncs your .env files for your team.
A software engineer that specializes in serverless microservices. I love creating helpful content about programming and reverse-engineering.
I am employed at Google; all opinions are my own.
I think @ravavyr is largely spot on here.
That said, .env files do have their weaknesses. We are addressing those with dotenv-vault - from the same people that pioneered dotenv.
every single security measure has its weaknesses, going by the original post here, using .ENV files is a thousand times simpler than what he proposes and maybe slightly less secure, but a thousand times easier to repair in case of an attack than the original post's process. That's all i was getting at and this thing blew up lol
At the end of the day, your dotenv-vault is functioning like a config server.
At that point it doesn't matter who's spot, this is a win for me in my books and my principles are still in play!!
Good job, can't wait to try it out and see people using my principles whether they know it or not š.
Yes, you are correct.
I think we are toward the same end here. You recognize the problem we see as well.
But throwing out the .env file will be a mistake. They need to work together. The config server should layer on top of .env files.
Currently, all implementations of config servers require you to learn a new proprietary system, rewrite code, and get locked into it. Plus, there is training on the new system for your dev team.
That's why we think all config servers should be built on top of the defacto .env file standard. This way, you get all the security benefits of .env files PLUS solve the insecure sharing and config issues.
That is what we are doing with dotenv-vault.
This has the added benefit that you could choose to leave dotenv-vault, and everything would still work. Or you could switch to a different provider that syncs your .env files for your team.
Sounds good to me no matter the underlying system as long as the benefits listed in my article gets implemented.
But seriously guys good job, it feels good to have the brains behind the bases of my very argument make amends with me. Iām so happy right now!!