Fedora has issued an advisory on June 26: https://lists.fedoraproject.org/pipermail/package-announce/2015-July/161539.html The issue (and another security issue with no CVE) is fixed upstream in 1.9.2. For some reason 1.9.2 isn't in the upstream Changelog: https://github.com/ansible/ansible/blob/devel/CHANGELOG.md but I do see a security issue fixed in 1.8.3 listed there. Mageia 4 and Mageia 5 are also affected. Reproducible: Steps to Reproduce:
Whiteboard: (none) => MGA5TOO, MGA4TOO
Updated to upstream 1.9.2 in both versions 4, 5 and cauldron
Status: NEW => ASSIGNEDCC: (none) => brunoAssignee: bruno => qa-bugs
Version: Cauldron => 5Whiteboard: MGA5TOO, MGA4TOO => MGA4TOO
More details on security issues fixed in 1.9.2: http://www.openwall.com/lists/oss-security/2015/07/14/3 http://www.openwall.com/lists/oss-security/2015/07/14/4
Package lists from madb: Mageia 4 partial match *** Arch: i586 *** RPMs from 'core-updates_testing' ======================== ansible-1.9.2-1.mga4.noarch.rpm SRPMs from 'core-updates_testing' ======================== ansible-1.9.2-1.mga4.src.rpm *** Arch: x86_64 *** RPMs from 'core-updates_testing' ======================== ansible-1.9.2-1.mga4.noarch.rpm SRPMs from 'core-updates_testing' ======================== ansible-1.9.2-1.mga4.src.rpm Mageia 5 partial match *** Arch: i586 *** RPMs from 'core-updates_testing' ======================== ansible-1.9.2-1.mga5.noarch.rpm SRPMs from 'core-updates_testing' ======================== ansible-1.9.2-1.mga5.src.rpm *** Arch: x86_64 *** RPMs from 'core-updates_testing' ======================== ansible-1.9.2-1.mga5.noarch.rpm SRPMs from 'core-updates_testing' ======================== ansible-1.9.2-1.mga5.src.rpm
This is not just a security update, the package is totally different (at least in Mageia 4) now. Lots of files added to /usr/lib/python2.7/site-packages/ansible/ Lots of files deleted from /usr/share/ansible/ and /usr/share/man/man3/ Are we sure we're not going to cause regressions? There can be arguments towards the use of the latest version of ansible, but as far as QA is concerned, patches fixing the issue would make things easier. Otherwise we need arguments as to why an exception to the policy is needed.
It's not an exception, and this is no different from how ansible has been handled in the past. There are no patches that I'm aware of, and it's not even entirely clear what all of the issues are. Obviously, hopefully there aren't any backward compatibility issues. I don't recall there being any in the past.
yes I confirm, I'm using ansible every day at work and this upgrade can't cause any trouble.
CC: (none) => makowski.mageia
(In reply to David Walser from comment #5) > It's not an exception, and this is no different from how ansible has been > handled in the past. You probably mean it's a recurring exception to the policy. It can be the way it's always been done and remain an exception.
(In reply to Samuel VERSCHELDE from comment #7) > (In reply to David Walser from comment #5) > > It's not an exception, and this is no different from how ansible has been > > handled in the past. > > You probably mean it's a recurring exception to the policy. It can be the > way it's always been done and remain an exception. No, I mean that sometimes for security updates we have to update things. That's not an exception, that is the policy. We do the best we can. I guess this is all semantics. Security updates might be an exception to the updates policy, but this is not an exception to the security updates policy. Anyway, that doesn't matter. There's no need to question security updates in this manner, as I'll handle that if a packager does the wrong thing. I am glad that you're checking the rpmdiffs though.
tested ok under Mga4 64 (generic test only) only a simple test with a distant box where you have ssh access and your ssh-key setup in : create a file, for example /tmp/hosts with the ip address if the distant box: $ cat /tmp/hosts 192.168.0.51 $ ansible -i /tmp/hosts all -m ping 192.168.0.51 | success >> { "changed": false, "ping": "pong" }
Whiteboard: MGA4TOO => MGA4TOO MGA4-64-OK
MGA4-32 on AcerD620 Xfce No installation issues. I set up a file as per Comment 9, and first checked I could connect with the ssh command: works OK But at CLI: ansible -vvvv -i /tmp/hosts all -m ping <192.168.2.5> ESTABLISH CONNECTION FOR USER: tester4 <192.168.2.5> REMOTE_MODULE ping <192.168.2.5> EXEC ssh -C -tt -vvv -o ControlMaster=auto -o ControlPersist=60s -o ControlPath="/home/tester4/.ansible/cp/ansible-ssh-%h-%p-%r" -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o ConnectTimeout=10 192.168.2.5 /bin/sh -c 'mkdir -p $HOME/.ansible/tmp/ansible-tmp-1438008800.08-230474921321688 && chmod a+rx $HOME/.ansible/tmp/ansible-tmp-1438008800.08-230474921321688 && echo $HOME/.ansible/tmp/ansible-tmp-1438008800.08-230474921321688' 192.168.2.5 | FAILED => SSH Error: Permission denied (publickey,password,keyboard-interactive). while connecting to 192.168.2.5:22 It is sometimes useful to re-run the command using -vvvv, which prints SSH debug output to help diagnose the issue.
CC: (none) => herman.viaene
Herman, you need to have ssh access using your ssh key in order to test.
Tested fine on MGA5-64-OK (Acer laptop): [shlomif@localhost ~]$ ansible -i /tmp/hosts all -m ping 10.0.0.5 | success >> { "changed": false, "ping": "pong" } 10.0.0.10 | success >> { "changed": false, "ping": "pong" } [shlomif@localhost ~]$ cat /tmp/hosts 10.0.0.5 10.0.0.10 [shlomif@localhost ~]$ [shlomif@localhost ~]$ rpm -q ansible ansible-1.9.2-1.mga5 Marking as has_procedure and MGA5-64-OK. Regards, -- Shlomi Fish
CC: (none) => shlomifWhiteboard: MGA4TOO MGA4-64-OK => MGA4TOO MGA4-64-OK MGA5-64-OK has_procedure
Keywords: (none) => validated_updateWhiteboard: MGA4TOO MGA4-64-OK MGA5-64-OK has_procedure => MGA4TOO MGA4-64-OK MGA5-64-OK has_procedure advisoryCC: (none) => davidwhodgins, sysadmin-bugs
An update for this issue has been pushed to Mageia Updates repository. http://advisories.mageia.org/MGASA-2015-0292.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED
CVE-2015-6240 was assigned for one of the issues fixed in this update: http://openwall.com/lists/oss-security/2015/08/17/10
Summary: ansible new security issue CVE-2015-3908 => ansible new security issues CVE-2015-3908 and CVE-2015-6240