Important security issue in puppet : http://puppetlabs.com/security/cve/cve-2013-3567/ Updated packages are available for testing for Mageia 2 and 3 in updates_testing : SRPMS: puppet-2.7.22-1.mga2 puppet-2.7.22-1.mga3 Mageia 2 packages : puppet-2.7.22-1.mga2.noarch.rpm puppet-server-2.7.22-1.mga2.noarch.rpm Mageia 3 packages : puppet-2.7.22-1.mga3.noarch.rpm puppet-server-2.7.22-1.mga3.noarch.rpm Reproducible: Steps to Reproduce:
Thanks Nicolas. Ubuntu has issued an advisory for this on June 18: http://www.ubuntu.com/usn/usn-1886-1/ Advisory: ======================== Updated puppet packages fix security vulnerability: It was discovered that Puppet incorrectly handled YAML payloads. An attacker on an untrusted client could use this issue to execute arbitrary code on the master (CVE-2013-3567). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-3567 http://puppetlabs.com/security/cve/cve-2013-3567/ http://www.ubuntu.com/usn/usn-1886-1/ ======================== Updated packages in core/updates_testing: ======================== puppet-2.7.22-1.mga2 puppet-server-2.7.22-1.mga2 puppet-2.7.22-1.mga3 puppet-server-2.7.22-1.mga3 from SRPMS: puppet-2.7.22-1.mga2.src.rpm puppet-2.7.22-1.mga3.src.rpm
URL: (none) => http://lwn.net/Vulnerabilities/555463/CC: (none) => luigiwalserHardware: x86_64 => AllSummary: puppet CVE-2013-3567 (Unauthenticated Remote Code Execution Vulnerability) => puppet Unauthenticated Remote Code Execution Vulnerability (CVE-2013-3567)
Advisory file has been added to svn.
According to release notes, the fix for this vulnerability is the only change in this release. http://docs.puppetlabs.com/puppet/2.7/reference/release_notes.html
puppet3 packages have also been updated in Mageia 3, from version 3.1.1 to 3.2.2. This update brings more changes according to release notes, but it's supposed to be backward compatible. Unfortunately no 3.1.x release exist, and backporting the fix from 3.2.2 does not seem simple, so the most simple solution is to update to 3.2.2. Updated packages in core/updates_testing: ======================== puppet-2.7.22-1.mga2 puppet-server-2.7.22-1.mga2 puppet-2.7.22-1.mga3 puppet-server-2.7.22-1.mga3 emacs-puppet-2.7.22-1.mga3 vim-puppet-2.7.22-1.mga3 puppet3-3.2.2-1.mga3 puppet3-server-3.2.2-1.mga3 vim-puppet3-3.2.2-1.mga3 emacs-puppet3-3.2.2-1.mga3 from SRPMS: puppet-2.7.22-1.mga2 puppet-2.7.22-1.mga3 puppet3-3.2.2-1.mga3
Whiteboard: (none) => MGA2TOO
Testing mga3 64 & 32 Largely following http://wiki.gentoo.org/wiki/Puppet to serve a file in each direction.
Whiteboard: MGA2TOO => MGA2TOO has_procedure
Testing complete mga3 32 & 64 Note that before using the agent as the puppetmaster for testign the other direction it is necessary to clear up. I found removing puppet completely and rm -rf /var/lib/puppet and /etc/puppet and starting again was easiest. There is probably a puppety way to do it but the instructions it gives when it fails to start the server don't seem to correct it. Also there is a warning on every use of puppet : /usr/share/ruby/gems/rubygems/custom_require.rb:36:in `require': iconv will be deprecated in the future, use String#encode instead. Nicolas, is this anything to be concerned about? It isn't a regression and doesn't affect the operation but will possibly fill logs.
Whiteboard: MGA2TOO has_procedure => MGA2TOO has_procedure mga3-32-ok mga3-64-ok
Testing mga2 now
Testing complete mga2 32 & 64 Validating Could sysadmin please push from 2 & 3 core/updates_testing to core/updates Thanks!
Keywords: (none) => validated_updateWhiteboard: MGA2TOO has_procedure mga3-32-ok mga3-64-ok => MGA2TOO has_procedure mga3-32-ok mga3-64-ok mga2-32-ok mga2-64-okCC: (none) => sysadmin-bugs
(In reply to claire robinson from comment #6) > Testing complete mga3 32 & 64 Thanks. Did you test both puppet and puppet3 packages ? > Also there is a warning on every use of puppet : > > /usr/share/ruby/gems/rubygems/custom_require.rb:36:in `require': iconv will > be deprecated in the future, use String#encode instead. > > Nicolas, is this anything to be concerned about? It isn't a regression and > doesn't affect the operation but will possibly fill logs. I think it's not very important.
(In reply to Nicolas Vigier from comment #9) > (In reply to claire robinson from comment #6) > > Testing complete mga3 32 & 64 > > Thanks. Did you test both puppet and puppet3 packages ? hrmm no, just puppet :\ So retesting needed on mga3 with puppet3 still.
Keywords: validated_update => (none)Whiteboard: MGA2TOO has_procedure mga3-32-ok mga3-64-ok mga2-32-ok mga2-64-ok => MGA2TOO has_procedure mga2-32-ok mga2-64-ok
I've run out of time today. In testing puppet3 the cert was signed ok but it fails on permission problems when trying to transfer the file, which is just configuration I'm sure. Any idea's on this Nicolas?
I think this is a setting in /etc/puppet/auth.conf but not sure what to set.. Pasting the error message in case it helps. Error: /Stage[main]//Node[default]/File[/etc/motd]: Could not evaluate: Error 400 on SERVER: Not authorized to call find on /file_metadata/files/motd with {:links=>"manage"} Could not retrieve file metadata for puppet://puppet/files/motd: Error 400 on SERVER: Not authorized to call find on /file_metadata/files/motd with {:links=>"manage"}
Found the solution. It needed more than a skim over the text on fileserver.conf Added this to then end there and all is OK. [files] path /var/lib/puppet/files allow * Validating again, sorry for missing it originally.
Keywords: (none) => validated_updateWhiteboard: MGA2TOO has_procedure mga2-32-ok mga2-64-ok => MGA2TOO has_procedure mga2-32-ok mga2-64-ok mga3-32-ok mga3-64-ok
http://advisories.mageia.org/MGASA-2013-0187.html
Status: NEW => RESOLVEDResolution: (none) => FIXED
Created attachment 4171 [details] build system web interface Nicolas, is seems that the build system still tries uselessly from time to time to build the 'puppet' package you submitted about a week ago to 'infra_2', perhaps this problem should be addressed.
CC: (none) => gruescubogdan