Add variable to disable Ansible security check
ganto opened this issue · comments
With a bit of a bad gut feeling i saw #338 being merged without any further discussion. Unfortunately I didn't have time last week to care. Today I wanted to do some DebOps work in my local containers when commuting in the train, I updated the DebOps roles before I left home.
Being offline I then found out:
fatal: [mail01 -> localhost]: FAILED! => {
"assertion": "((ansible_version.minor == 2) and (ansible_version.full | version_compare(\"2.2.1.0\", \">=\"))) or (ansible_version.minor != 2)",
"changed": false,
"evaluated_to": false,
"failed": true,
"msg": "VULNERABLE Ansible version DETECTED, please update Ansible to the stable-2.1 branch (> v2.1.4) or a newer Ansible release (>= v2.2.1)! Check the debops-playb
ook changelog for details. Exiting."
}
That's on a local LXC container with a Debian Jessie installed about one month ago.
Guys seriously...? Please add a way that this test can be skipped. There are many valid reasons why someone would like to use DebOps even he runs on a vulnerable version. For examples:
- DebOps is used to bisect some issues with Ansible which would include vulnerable versions
- DebOps is used on a system that is offline or other reasons e.g. upgrade policies prevent Ansible from being updated
- and especially important: DebOps is used to update Ansible to a non-vulnerable version
I manage security updates on thousands of systems, I'm aware that software should be up-to-date but I'm also a grown up administrator which decides itself when to update. When I'm developing, then I wish to develop, not managing my development machines...
First, to get it out of the way: @ganto, do you think that tagging the "Security assertions" play with something like, play::security-assertions
, which would let you do:
debops --skip-tags play::security-assertions -l <host>
would be enough? I checked on my installation and it correctly skips the task, I can add it right away.
Second, I suppose that the project is now used by so much people and so many environments that more "visible" changes might require a proper review and discussion. I'll try to keep that in mind the next time something like that happens. Having more eyes on the project would definitely help. @ganto, have you thought about joining the project as a developer? How's your GPG public key these days?
Hey guys
There was some discussion going on about this for a while and I know your @ganto position on this. For reference: ansible/ansible#18375 from which most other PR and issues should be referred to. @drybjed and me also discussed this abit. I still think that this assertion overweights the downsides you mentioned by far. Most users are unaware. The proposal with play::security-assertions
sounds like the proper solution for this.
Fixed by: #340
First, to get it out of the way: @ganto, do you think that tagging the "Security assertions" play with something like, play::security-assertions
Sounds good to me 👍 @drybjed Thanks for the fast response and fix.
There was some discussion going on about this for a while and I know your @ganto position on this.
I thought so and that's the reason why I was a bit surprised seeing the PR being merged without switch. I decided not to care as I'm currently having other things on my plate and I wanted to see how long it takes until someone steps over this. Eventually it was definitely annoying to find out that it would be myself. 😏
@ganto, have you thought about joining the project as a developer? How's your GPG public key these days?
I'll soon have some holiday again. Hope I'll find time to do a proper GPG setup this time.
As the issue is resolved now, I'll close this thread.