-
Notifications
You must be signed in to change notification settings - Fork 11
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
Various small fixes #109
Various small fixes #109
Conversation
|
GitGuardian id | GitGuardian status | Secret | Commit | Filename | |
---|---|---|---|---|---|
- | Username Password | c0997fd | provision-contest/ansible/group_vars/all/secret.yml.example | View secret | |
- | Username Password | c7e0490 | provision-contest/ansible/group_vars/all/secret.yml.example | View secret | |
- | Generic Password | c7e0490 | provision-contest/ansible/group_vars/all/secret.yml.example | View secret |
🛠 Guidelines to remediate hardcoded secrets
- Understand the implications of revoking this secret by investigating where it is used in your code.
- Replace and store your secrets safely. Learn here the best practices.
- Revoke and rotate these secrets.
- If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.
To avoid such incidents in the future consider
- following these best practices for managing and storing secrets including API keys and other credentials
- install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.
🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.
Our GitHub checks need improvements? Share your feedbacks!
f74d1b4
to
28fa4f3
Compare
@@ -1,53 +1,53 @@ | |||
# Password for the MySQL replication user. | |||
# Set this to enable master-master replication between two domservers. | |||
#REPLICATION_PASSWORD: some-replication-password | |||
#REPLICATION_PASSWORD: {some-strong-replication-password} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are the {}
part of the password?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an example file, and no I use them as anchors to replace them in the script I added.
Normally we would cp secret.yml{example,}
and then replace the passwords by manually running xkcdpass, I now tried to automate this to make sure we always use unique ones.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we should document this?
Also we still manually need to enable replication, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you would want replication yes, we now fill in the password but its still commented out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My question was because if someone does it manually, then this format suggests to keep the {}
surrounding the password, which they probably should not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've now documented it
@@ -1,53 +1,53 @@ | |||
# Password for the MySQL replication user. | |||
# Set this to enable master-master replication between two domservers. | |||
#REPLICATION_PASSWORD: some-replication-password | |||
#REPLICATION_PASSWORD: {some-strong-replication-password} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we should document this?
Also we still manually need to enable replication, right?
@@ -0,0 +1,31 @@ | |||
#!/usr/bin/env python3 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will this script be called in some Makefile (later)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did not do that yet, and not sure if we would want that so I prefer to do that outside of this PR.
8c0b738
to
ce6f381
Compare
This simplifies setting up the contests and makes that we set reasonable strength passwords by default. In case you make multiple groups (for example WF4{47}) we can work from the templates set in git.
In most of our contests we only deploy the admin & presentation accounts.
This make overwriting much easier and when we debug by printing all variables this now showes up. We can now also override/extend it directly in the group.
Make the picked ansible folder explicit to remove the warning
In case we ever want to deploy a contest where we do have internet.
Getting the subgroups seems to be non-trivial and in most cases the emergency laptop would be handled different from the main servers.
We only deploy on debian/ubuntu where all php modules are prefixed with `php-`
This makes it easier for other users to use our scripts or consider those usecases.
ce6f381
to
77782c6
Compare
Added a script to fill the passwords
Some small code cleanup