Upstream has released version 34.0.1847.116 on April 8: http://googlechromereleases.blogspot.com/2014/03/stable-channel-update_14.html This fixes a handful of new security issues. This is the current version in the stable channel: http://googlechromereleases.blogspot.com/search/label/Stable%20updates Reproducible: Steps to Reproduce:
A user has claimed in Bug 13118 that Flash will no longer work as of this Chromium version, and that we will need a non-free package to download and install Chrome's Pepper Flash like we have now for Adobe Flash. I haven't been able to verify this. If true, it will certainly complicate this update. CC'ing Pascal and Anssi who may have some insight and/or interest in this.
CC: (none) => anssi.hannula, pterjanWhiteboard: (none) => MGA4TOO, MGA3TOO
If true, I'd say the best way forward probably is to: 1. Provide "flash-player-plugin-pepper" or similar in the same way as "flash-player-plugin", and 2. Have it installed somehow: (a) Have it as a suggests in "flash-player-plugin": Pros: Users using flash-player-plugin will continue to get flash. Cons: Non-chromium users will get it for no reason. (apparently it also requires explicit changes in Chromium package to get it to use our separately packaged flash. (b) Have it as a suggests on "chromium": Pros: Only chromium users will get it. Cons: Flash-less users that have non-free media enabled will have Flash installed. (c) Something way better I'm not seeing? I'm probably leaning towards (a), any other opinions? In the meantime I'll verify that this is really the case, and then post on dev@ just to get a wider audience, while creating a flash-player-plugin-pepper package.
Depends on: (none) => 13118
Thanks Anssi. I would say that option (b) sounds like it makes more sense to me. Pepper is only relevant to chromium users, they probably want it, so the Suggests is good, and if they really don't want it, they should be able to just uninstall it and it shouldn't come back.
David: Sure, but is that how Suggests work? I was under the impression that they would come back on every update... though maybe that has changed in the recent years without me noticing? Anyway, looks like the NPAPI removal schedule was changed and it was only removed on Chromium 34+: http://blog.chromium.org/2014/04/chrome-35-beta-more-developer-control.html So this is not needed for this update yet, but in a month or so.
Depends on: 13118 => (none)
(In reply to Anssi Hannula from comment #4) > David: Sure, but is that how Suggests work? I was under the impression that > they would come back on every update... though maybe that has changed in the > recent years without me noticing? Reading the code it indeed has changed, good. So I'll probably be in favor of that options as well. One another thing is that maybe we will see support for pepper in other browsers if/when Adobe drops support for NPAPI completely (or earlier)... but we can just switch the suggest at that point then I guess.
Anssi, thanks for the research. And yes, as far as the Suggests thing, it did used to work in a way that it would come back with every update, and I mentioned this on the -dev list at some point and tv said he'd fixed that.
Another issue is during the build, a bundled tool called tools/gn/bin/linux/gn is called, and until recently this binary was included in the source tarball, but a few releases ago, it got dropped even though it's still needed. ROSA bundled it up (probably from the last chromium tarball that had it) into a separate tarball and included that in their SRPM, and I do the same. In their build of 34 from today, they included a patch linked from this upstream bug: https://codereview.chromium.org/142853004/ which if I'm reading it correctly, applying this patch would make it not call that gn binary during the build (although ROSA didn't drop including it in their SRPM), but upstream's reaction to the patch is you shouldn't be using make to build it, you should be using ninja (which I guess is some other tool we don't have packaged) and then it will use gn, which hopefully is either included with ninja, or building with ninja knows how to produce this binary during the build somehow, since it still isn't included in the source tarball. The other things I noticed from their commit: https://abf.rosalinux.ru/import/chromium-browser-stable/commit/099bf7ae8651f2da3dd796211c0b3cbaeccbdf78 is that chrome.pak is apparently no longer built (not sure the implications of that) and icudtl.dat needs to be installed (the path used by the install command was fixed in a later commit), which makes sense since it's building a bundled icu rather than using the system one.
I have imported ninja into Cauldron, not tried to use it yet.
(In reply to Pascal Terjan from comment #8) > I have imported ninja into Cauldron, not tried to use it yet. Thanks. I wouldn't know how to, so hopefully you'll be able to figure out the necessary SPEC file machinations to make use of it :o)
Building with ninja by itself was easy but build/gyp_chromium was failing to find depot_tools, whether I use make or ninja. depot_tools is the git repository containing binary version of ninja, gn and other stuff for linux-32, linux-64, mac, windows so I had to patch it to not search for it. Then I reached the missing chrome.pak and went to sleep. I committed current state this morning.
Oh and for gn, its sources are in the chrome sources so the solution is probably to build it. I tried: python tools/gn/bootstrap/bootstrap.py which successfully built it, but then it failed to rebuilt itself: [224/224] LINK gn Building gn using itself to out/Release... ERROR at //device/usb/BUILD.gn:6:17: File is not inside output directory. generated_ids = "$target_gen_dir/usb_ids_gen.cc" Will look more into it later.
Cauldron version building with a gn built from source, I still haven't updated the list of files to install.
Untested build uploaded to Cauldron, I won't be able to test it before at least Sunday evening.
My testing on cauldron leads quite quickly to a segfault :( #0 __cxxabiv1::__dynamic_cast (src_ptr=0x7fffac1a8550, src_type=0x7ffff47bcff0 <typeinfo for google::protobuf::MessageLite>, dst_type=0x7ffff47bec40 <typeinfo for google::protobuf::Message>, src2dst=0) at ../../../../libstdc++-v3/libsupc++/dyncast.cc:60 #1 0x00007ffff45674ce in google::protobuf::Message::CheckTypeAndMergeFrom(google::protobuf::MessageLite const&) () from /lib64/libprotobuf.so.8 #2 0x0000555558d4adbd in gcm::MCSMessage::CloneProtobuf() const () #3 0x0000555558d613df in gcm::MCSClient::SendMessage(gcm::MCSMessage const&) () #4 0x0000555558d65998 in gcm::MCSClient::HandleMCSDataMesssage(scoped_ptr<google::protobuf::MessageLite, base::DefaultDeleter<google::protobuf::MessageLite> >) () #5 0x0000555558d65bc8 in gcm::MCSClient::HandlePacketFromWire(scoped_ptr<google::protobuf::MessageLite, base::DefaultDeleter<google::protobuf::MessageLite> >) () #6 0x0000555558d5c52c in base::internal::Invoker<1, base::internal::BindState<base::internal::RunnableAdapter<void (gcm::MCSClient::*)(scoped_ptr<google::protobuf::MessageLite, base::DefaultDeleter<google::protobuf::MessageLite> >)>, void (gcm::MCSClient*, scoped_ptr<google::protobuf::MessageLite, base::DefaultDeleter<google::protobuf::MessageLite> >), void (base::WeakPtr<gcm::MCSClient>)>, void (gcm::MCSClient*, scoped_ptr<google::protobuf::MessageLite, base::DefaultDeleter<google::protobuf::MessageLite> >)>::Run(base::internal::BindStateBase*, scoped_ptr<google::protobuf::MessageLite, base::DefaultDeleter<google::protobuf::MessageLite> >) () #7 0x0000555558d4f8d0 in gcm::ConnectionHandlerImpl::OnGotMessageBytes() () #8 0x0000555558d501ae in gcm::ConnectionHandlerImpl::WaitForData(gcm::ConnectionHandlerImpl::ProcessingState) () #9 0x0000555558d70677 in gcm::SocketInputStream::RefreshCompletionCallback(base::Callback<void ()> const&, int) () #10 0x00005555563f0107 in base::internal::Invoker<1, base::internal::BindState<base::Callback<void (int)>, void (int), void (int)>, void (int)>::Run(base::internal::BindStateBase*) () #11 0x000055555668c01d in net::SSLClientSocketNSS::Core::PostOrRunCallback(tracked_objects::Location const&, base::Callback<void ()> const&) () #12 0x0000555556503587 in base::MessageLoop::RunTask(base::PendingTask const&) () #13 0x0000555556504491 in base::MessageLoop::DeferOrRunPendingTask(base::PendingTask const&) () #14 0x0000555556506cb5 in base::MessageLoop::DoWork() () #15 0x00005555564d0f88 in base::MessagePumpLibevent::Run(base::MessagePump::Delegate*) () #16 0x0000555556508e4b in base::MessageLoop::RunHandler() () #17 0x0000555556526648 in base::RunLoop::Run() () #18 0x0000555556502805 in base::MessageLoop::Run() () #19 0x0000555558699be5 in content::BrowserThreadImpl::IOThreadRun(base::MessageLoop*) () #20 0x0000555558699cfb in content::BrowserThreadImpl::Run(base::MessageLoop*) () #21 0x000055555653df33 in base::Thread::ThreadMain() () #22 0x00005555565391ac in base::(anonymous namespace)::ThreadFunc(void*) () #23 0x00007ffff47cafab in start_thread (arg=0x7fffc9568700) at pthread_create.c:309 #24 0x00007ffff132918d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/LwxBNJZMNBI
So we need to switch back to using the bundled protobuf (Mageia 3 still is).
Yes that seems the best solution :(
Nice as it is to be able to use system libraries, I don't think it's a big deal, especially for a not-heavily-used library like protobuf, considering how frequently updated chromium is. Using the bundled one really doesn't cost anything.
It seems to be working fine in cauldron. How to proceed next? Upload ninja to updates_testing for 3 and 4 and then chromium?
Yes indeed! Thanks Pascal! We have to submit the build in both core and tainted.
All done apart from 3/tainted which is still building
Updated packages uploaded for Mageia 3, Mageia 4, and Cauldron. Note to QA: there are both core and tainted builds for this package. There are more changes in this update than usual. We've changed the way it's built from using make to using a build tool called ninja, which we had to backport for this update. Ninja doesn't really need to be tested by QA, as we already know it works since it was successfully used to build chromium. Also, the chrome.pak file is no longer part of the package. Finally, on Mageia 4 it is using a bundled protobuf library again (as it has been on Mageia 3) instead of the system one. Also, I just noticed that I pasted the wrong link in Comment 0, but it's correct in the references below. Advisory: ======================== Updated chromium-browser-stable packages fix security vulnerabilities: Multiple vulnerabilities in the V8 JavaScript library, including a UXSS issue (CVE-2014-1716), OOB access (CVE-2014-1717), memory corruption (CVE-2014-1721), and other vulnerabilities fixed in V8 version 3.24.35.22 (CVE-2014-1729). Integer overflow in compositor (CVE-2014-1718). Multiple use-after-free flaws; in web workers (CVE-2014-1719), DOM (CVE-2014-1720), rendering (CVE-2014-1722), speech (CVE-2014-1724), and forms (CVE-2014-1727). Url confusion with RTL characters (CVE-2014-1723). OOB read with window property (CVE-2014-1725). Local cross-origin bypass (CVE-2014-1726). Various fixes from internal audits, fuzzing and other initiatives (CVE-2014-1728). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1716 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1717 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1718 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1719 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1720 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1721 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1722 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1723 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1724 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1725 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1726 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1727 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1728 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1729 http://googlechromereleases.blogspot.com/2014/04/stable-channel-update.html ======================== Updated packages in core/updates_testing: ======================== chromium-browser-stable-34.0.1847.116-2.mga3 chromium-browser-34.0.1847.116-2.mga3 ninja-1.4.0-1.mga3 chromium-browser-stable-34.0.1847.116-2.mga4 chromium-browser-34.0.1847.116-2.mga4 ninja-1.4.0-1.mga4 Updated packages in tainted/updates_testing: ======================== chromium-browser-stable-34.0.1847.116-2.mga3 chromium-browser-34.0.1847.116-2.mga3 chromium-browser-stable-34.0.1847.116-2.mga4 chromium-browser-34.0.1847.116-2.mga4 from SRPMS: chromium-browser-stable-34.0.1847.116-2.mga3.src.rpm ninja-1.4.0-1.mga3.src.rpm chromium-browser-stable-34.0.1847.116-2.mga4.src.rpm ninja-1.4.0-1.mga4.src.rpm
Version: Cauldron => 4Whiteboard: MGA4TOO, MGA3TOO => MGA3TOO
Debian has issued an advisory for this on April 15: https://www.debian.org/security/2014/dsa-2905
URL: (none) => http://lwn.net/Vulnerabilities/595032/
Oops, somehow this didn't get assigned to QA. Please see all the notes and information in Comment 22.
Assignee: bugsquad => qa-bugs
Testing complete mga4 64 https, java, flash, sign-in, apps, browsing, javascript with sunspider
Whiteboard: MGA3TOO => MGA3TOO has_procedure mga4-64-ok
Testing complete mga3 64 and mga4 32 Needs testing mga3 32 to validate
Whiteboard: MGA3TOO has_procedure mga4-64-ok => MGA3TOO has_procedure mga3-64-ok mga4-32-ok mga4-64-ok
In VirtualBox, M3, KDE, 32-bit Package(s) under test: chromium-browser-stable default install of chromium-browser-stable [root@localhost wilcal]# urpmi chromium-browser-stable Package chromium-browser-stable-33.0.1750.152-1.mga3.tainted.i586 is already installed Chromium displays cnn.com, google.com and YouTube.com (videos) just fine. install chromium-browser-stable from updates_testing [root@localhost wilcal]# urpmi chromium-browser-stable Package chromium-browser-stable-34.0.1847.116-2.mga3.tainted.i586 is already installed Chromium displays cnn.com, google.com and YouTube.com (videos) just fine. Test platform: Intel Core i7-2600K Sandy Bridge 3.4GHz GIGABYTE GA-Z68X-UD3-B3 LGA 1155 MoBo GIGABYTE GV-N440D3-1GI Nvidia GeForce GT 440 (Fermi) 1GB RTL8111/8168B PCI Express 1Gbit Ethernet DRAM 16GB (4 x 4GB) Mageia 4 64-bit, Nvidia driver VirtualBox 4.3.6-1.mga4.x86_64.rpm
CC: (none) => wilcal.intWhiteboard: MGA3TOO has_procedure mga3-64-ok mga4-32-ok mga4-64-ok => MGA3TOO has_procedure mga3-32-ok mga3-64-ok mga4-32-ok mga4-64-ok
For me this update works fine. Testing complete for mga3 32-bit & 64-bit Testing complete for mga4 32-bit & 64-bit Validating the update. Could someone from the sysadmin team push this to updates. Thanks
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
Please do not ask for sysadmin to push an update when there is no advisory uploaded. Waiting.
Keywords: validated_update => (none)CC: sysadmin-bugs => mageia
Until recently this was done by sysadmins Damien, as you know. You could be a bit flexible here, we are not here to provide secretarial services. SVN works as well for you as it does for us. The update is validated, there is no reason to remove the keyword. I will upload an advisory shortly if this simple task is causing a roadblock to pushing a security update.
Update tested, validated and advisory uploaded. Missing Tainted SRPM's added to advisory.
Whiteboard: MGA3TOO has_procedure mga3-32-ok mga3-64-ok mga4-32-ok mga4-64-ok => MGA3TOO has_procedure advisory mga3-32-ok mga3-64-ok mga4-32-ok mga4-64-ok
As you said: "Until recently". Moreover secretarial services are not a shame. http://advisories.mageia.org/MGASA-2014-0183.html
Status: NEW => RESOLVEDResolution: (none) => FIXED
(In reply to Damien Lallement from comment #32) > As you said: "Until recently". Perhaps our flexibility is something we need to revisit if sysadmin are forming a stance of inflexibility. > Moreover secretarial services are not a shame. Feel free to provide them then..