-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Add no_log to some module arguments #1725
Conversation
This will prevent potentially sensitive information from being printed to the console. See: CVE-2021-20191
Co-authored-by: Felix Fontein <felix@fontein.de>
* Add no_log to some module arguments This will prevent potentially sensitive information from being printed to the console. See: CVE-2021-20191 * Update changelogs/fragments/CVE-2021-20191_no_log.yml Co-authored-by: Felix Fontein <felix@fontein.de> Co-authored-by: Felix Fontein <felix@fontein.de> (cherry picked from commit ae8edc0)
@dmsimard thanks for fixing this! |
* Add no_log to some module arguments This will prevent potentially sensitive information from being printed to the console. See: CVE-2021-20191 * Update changelogs/fragments/CVE-2021-20191_no_log.yml Co-authored-by: Felix Fontein <felix@fontein.de> Co-authored-by: Felix Fontein <felix@fontein.de> (cherry picked from commit ae8edc0)
@dmsimard I was enticed by this PR to run a grep on the repo, and I spotted:
I have not investigated thoroughly, it was just a grep and I excluded entries with Cheers PS:
from the |
* Add no_log to some module arguments This will prevent potentially sensitive information from being printed to the console. See: CVE-2021-20191 * Update changelogs/fragments/CVE-2021-20191_no_log.yml Co-authored-by: Felix Fontein <felix@fontein.de> Co-authored-by: Felix Fontein <felix@fontein.de> (cherry picked from commit ae8edc0) Co-authored-by: David Moreau Simard <dmsimard@redhat.com>
* Add no_log to some module arguments This will prevent potentially sensitive information from being printed to the console. See: CVE-2021-20191 * Update changelogs/fragments/CVE-2021-20191_no_log.yml Co-authored-by: Felix Fontein <felix@fontein.de> Co-authored-by: Felix Fontein <felix@fontein.de> (cherry picked from commit ae8edc0) Co-authored-by: David Moreau Simard <dmsimard@redhat.com>
@russoz please create a PR if you have a bit of time :) Actually we were thinking of extending the sanity tests to test for more possible keys and report errors if |
@russoz good find, thanks ! We can and should fix the instances where it's relevant and refer to the CVE like we did for this PR. |
@russoz hi, I had something roughly working, feel free to create a PR based on this branch https://github.com/gundalow/ansible/tree/ci-no-log |
I think most of these are valid and need fixes. Going through these:
I'm not sure if this is one (I believe it's used for public keys?), but it did lead me to find
Yep these seem valid.
This one already seems to set
Seem valid. Also in
Possibly. Reading the keycloak docs, this token is invalidated after it's used once, so it leaking probably isn't a huge deal.
Yep, I think so.
Yep, since this can be either a path to a key, or the key itself, it should be hidden.
Yep, yep. |
Whoever wants to create the PR for ansible-test should mention it here. If nothing happened until tomorrow, I might start working on that ;) |
…al#1725 Signed-off-by: Rick Elrod <rick@elrod.me>
…al#1725 Signed-off-by: Rick Elrod <rick@elrod.me>
…73488) Change: - A number of modules were missing no_log=True where they should have had it. Test Plan: - Lots of grepping. Tickets: - Refs ansible-collections/community.general#1725 Signed-off-by: Rick Elrod <rick@elrod.me>
…73489) Change: - A number of modules were missing no_log=True where they should have had it. Test Plan: - Lots of grepping. Tickets: - Refs ansible-collections/community.general#1725 Signed-off-by: Rick Elrod <rick@elrod.me>
If you are using |
It's passed as
I guess better safe than sorry :)
I think these are not (the one is an alias for the other, the other is passed on to the API as
The other two definitely not. I've created a PR for these: #1736 |
@felixfontein I didn't look in detail, but I googled earlier (as I was writing that comment) and found this page: https://support.pagerduty.com/docs/services-and-integrations which talks about generating service and integration API keys, so I assumed that was for that (in which case they are private api keys). But again I didn't look in much detail, maybe they're just misnomers in the module. Edit: I did mark them as |
@relrod good question, I found the API docs hard to navigate, so I'm not really sure. I've updated my PR to also mark them no_log, just in case :) |
@felixfontein Also I agree with "better safe than sorry" about the keycloak one. I didn't include it in the backport PRs (which I already merged), but I'm regretting that, and I think I'll fix it. Even if it can only be used once, if it gets logged/emitted in an error condition, there's a chance that it won't have been used (due to the error). I didn't think that through earlier. 😳 |
I've started creating a PR out of @gundalow's branch: ansible/ansible#73508 |
This will prevent potentially sensitive information from being printed to the console.
See: CVE-2021-20191