Updated package uploaded by Bruno for Mageia 7.

Advisory:
========================

Updated ansible package fixes security vulnerability:

Splunk and Sumologic callback plugins leak sensitive data in logs
(CVE-2019-14864).

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14864
https://github.com/ansible/ansible/blob/stable-2.7/changelogs/CHANGELOG-v2.7.rst
https://access.redhat.com/errata/RHSA-2019:3925
========================

Updated packages in core/updates_testing:
========================
ansible-2.7.15-1.mga7

from ansible-2.7.15-1.mga7.src.rpm

CC: (none) => bruno
Assignee: bruno => qa-bugs

Mageia7, x86_64

After trying to run simple commands with this and failing, tried the -k option.
$ ansible -k -i ~/tmp/hosts all -m ping
192.168..... | FAILED! => {
    "msg": "to use the 'ssh' connection type with passwords, you must install the sshpass program"
}
......

Mageia supplies sshpass.
$ sudo urpmi sshpass
Failed the first time because "SSH password:" requires the user password, not the SSH passphrase.

It is unlikely that the simple tests we run in QA would exercize the Splunk and Sumologic callback plugins (whatever they are).  If anybody knows more about those would they please speak up if there is any way we can incorporate them in testing.

Updated the package.
$ ansible -k -i ~/tmp/hosts all -m ping
SSH password: 
192.168.1.aaa | SUCCESS => {
    "changed": false,
    "ping": "pong"
}
192.168.1.bbb | SUCCESS => {
    "changed": false,
    "ping": "pong"
}
$ ansible -k -i /etc/ansible/hosts all -a "echo hello"
SSH password: 
192.168.1.aaa | CHANGED | rc=0 >>
hello

192.168.1.bbb | CHANGED | rc=0 >>
hello

The following worked perfectly on the local machine and launched OK on the other but failed to complete for reasons unconnected with ansible. 
$ ansible -k -i /etc/ansible/hosts all -a "/home/user/bin/wv 900"

$ ansible -k -i /etc/ansible/hosts all -a "stellarium"
That worked locally, and tried to run on the remote but could not proceed.  Again this is probably to be expected.

This command worked fine at both ends, displaying a Tk widget on both monitors.
$ ansible -k -i /etc/ansible/hosts all -a "/home/user/bin/chex"
SSH password: 
192.168.1.aaa | CHANGED | rc=0 >>

192.168.1.bbb | CHANGED | rc=0 >>

$ ansible -k -i /etc/ansible/hosts all -a "inxi -b"
SSH password: 
192.168.1.bbb | CHANGED | rc=0 >>
System:
  Host: canopus Kernel: 5.3.13-desktop-2.mga7 x86_64 bits: 64 
........
192.168.1.aaa | FAILED | rc=-9 >>
System:
  Host: difda Kernel: 5.3.13-desktop-2.mga7 x86_64 bits: 64 
[...]
  driver: r8169 non-zero return code

$ ansible -k -i ~/tmp/hosts all -a "mate-terminal -e 'inxi -b'"
SSH password: 
192.168.1.bbb | FAILED | rc=255 >>
non-zero return code

192.168.1.aaa | FAILED | rc=255 >>
non-zero return code

That command actually succeeded for the remote machine aaa, displaying a mate terminal on the local desktop entitled "<user prompt> (on difda)" and showing the output from inxi.  The FAILED probably resulted from the Ctrl-C used to close the terminal.  No idea why it failed for the local machine but perhaps we should bear in mind that ansible is probably designed for administrative tasks using self-managed processes not as an alternative to remote desktop applications.

Anyway, the general impression from these sparse tests is that ansible works fine.

CC: (none) => tarazed25
Whiteboard: (none) => MGA7-64-OK

Validating this.  Advisory in comment 1.

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2019-0358.html

Resolution: (none) => FIXED
Status: NEW => RESOLVED