tamutus / magnova

Platform for dividing the world's largest problems into collaborative projects
GNU General Public License v3.0
8 stars 1 forks source link

git secrets #3

Open AnarchoSystems opened 1 year ago

AnarchoSystems commented 1 year ago

Hey there,

I'd like to contribute, and I already kinda found an issue in the README.

Rather than passing around .env files, one should be using git secrets. The basic idea is that you encrypt whatever secret files you have with the public keys of everyone you want to be able to contribute; if you want to let others in on the secret, you decrypt on your local machine using your private key and re-encrypt with the new person's public key; and if you want to change the content of the secret, you once again decrypt, change, then re-encrypt. As far as I know (I never really used it myself, but I would use it if I had any sensitive info to communicate with a team in a public space), this is largely made implicit by the mentioned tool.

I'll come back to ya with more concrete ideas what I can contribute when I'm done reviewing ;)

tamutus commented 1 year ago

Welcome, and thank you for this insight! I was feeling insecure about that strategy and I'm very grateful to you for sharing an alternative. I did a cursory search of the reasoning for making such a switch and it makes sense to me!

AnarchoSystems commented 1 year ago

Thanks for the appreciation. Actually, there's an even better strategy now that I think about it...

I only know how you can achieve this with postgres, but it ought to be possible with other DBs as well: one can create a docker image of a running DB with the scheme used in production and maybe some random data, but the credentials would be public knowledge. Since each dev runs their own docker image (with very little data suitable for testing), there shouldn't be much of a security risk. Credentials for the production DB only need to be known by very few people who are authorized to deploy the app.

Not sure what other sensitive information this app has, but at least for the DB, this should be a very satisfying - though probably somewhat difficult to implement - solution.

Edit: I've googled it (source 1 and source 2), and it seems super easy, barely an inconvenience, even with mongo.