-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to manually set secrets #220
Comments
@Tristaan built the secrets generation engine here, I think. Any thoughts, Tristan ? |
From the tech call: I believe this is already doable and is just an order of operations problem. I'll test my theory really quick this afternoon and get back to you. |
Just tested this and it doesn't seem to be working now. |
@DonRichards I couldn't find a way to do it either. It seems to be baked into Another possible solution I am thinking about would be to remove USE_SECRETS (have it always be true) and instead add a variable called MANUAL_SECRETS. If manual secrets is set to true then it should not automatically generate them, but instead the user would have to copy the secrets/template folder into secrets/live. That way they could leave them all as "password" if they wanted to, or could manually update them before running My biggest concern with this is having someone go live with a production site that initially wasn't using secrets, and not realize that some of their passwords are "password" because they were not updated when turning on USE_SECRETS. |
@joshdentremont I just pushed an pull request on this to address most of this (I think) #226 |
I was @Tristaan 's supervisor at the company where he was tasked to create this. He's no longer employed at our company (as of 4 months ago) so I've taken over his duties. When this was PR'd, my intention was to incorporate a secrets-generating script that I had already written, that already did work correctly (it checks if live secrets already existed and didn't overwrite them, and supports random or template secrets types), it's also much simpler. Unfortunately his code was never confirmed by me, but was made into a PR anyway, which I didn't approve of. After his absence I didn't have time to immediately continue his work so it got put on hold. I didn't have time to work on this project so didn't have time to look at this issue sooner, but now that someone else has already made a PR for secrets handling that seems to be pretty far along, I don't know if it would be good for me to ask you to replace it with my script. I haven't evaluated that PR yet, to see if it's equivalent to my code or not. I can make a PR just to compare after I get the time and get back to this (hopefully next week) |
There doesn't seem to be a way to create your own secrets. When running make local it will generate random secrets, and if USE_SECRETS=true it will set the passwords to those secrets, otherwise it sets them to 'password'. Changing the secrets files, or changing USE_SECRETS after this initialization doesn't seem to do anything.
The biggest issue that I see with this is that if you follow the instructions for installing a production server it tells you to make local, then set USE_SECRETS=true, but if you do it in that order your passwords will all be 'password' because that's what they were originally set to when you ran make local.
I think the best solution would be to have a make command that changes all the passwords in our containers to the contents of secrets/live. Then we could just put a note in the sample.env that turning on USE_SECRETS requires running that command.
The text was updated successfully, but these errors were encountered: