Add variable to disable Ansible security check

[Reto Gantenbein]

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...

[Maciej Delmanowski]

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?

[Robin Schneider]

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

[Reto Gantenbein]

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.