dansup
Adding the ability to edit S3 api key/secret credentials is sketchy and requires careful consideration. Before: fetch from cached .env variables After: fetch from redis cache, if fails fetch from db, if fails fetch from cached .env vars Now we need to store api keys in the database and hydrate the cache with the values, so I'm encrypting the db values and decrypting them in the redis cache. Few db columns need this level of security, but I think I got this right 🤔 7 comments
dansup
@barbapulpe I'll leave that up to each admin to decide, you will have the ability to disable this entirely if you choose and just use ENV vars   
Raphael Lullis
What is the default? Who is your user? If someone can deploy this, it means they have access to the direct access to the server. Why should they have access to secrets through the admin?
Andy
@dansup I assume this has to do with the plans of offering hosting for Pixelfed, and ease of configuring when no server access is given but stuff like this should be handled in a hosting panel outside of the main app then. adding so much logic into the application to keep those values safe, when easier options are already there is a bit...counter-productive. and error-prone as well, and you don't want these secrets to get into the wrong hands! |
Gregory's Server
@dansup
Do we actually need the ability to edit S3 keys? This is a very rare task and multiplying the key storage to several locations does not seem good for security, to enable a task which does not require to be done from the UI in my opinion.