[opensuse-factory] Firefox new upgrades for current Opensuse versions - now sticking to ESR?
Hello list, in the past Firefox amonst some other select projects or applications kind of got upgrades instead of mere updates. Today or on the updates list I see that Firefox 52 becomes into 52.1.x ESR instead of 53. Is this an intentional change of procedure from the past? How come and where and how has this been discussed and decided. Would like to know and understand more of these kind of things. Thank you. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, Am 26.04.2017 um 17:17 schrieb cagsm:
It is intentional because of several reasons. Here is a list of things led to this decision: - Firefox requires rust mandatorily now to build https://bugzilla.opensuse.org/show_bug.cgi?id=1030232 - Firefox removed Gtk2 with FF53; Leap still used Gtk2 builds (Gtk3 should work but an unexpected change nevertheless) e.g. https://bugzilla.opensuse.org/show_bug.cgi?id=1022830 - Firefox requires updates for mozilla-nss in the same pace leading to issues like this: https://bugzilla.suse.com/show_bug.cgi?id=1026102 - Firefox 53 dropped NPAPI plugin support for everything but Flash https://bugzilla.opensuse.org/show_bug.cgi?id=1030515 For the moment all distributions and streams are on 52esr (including Tumbleweed) for the time being. Many of the things above are probably ok for Tumbleweed, some won't be for a set of users for quite some time (e.g. Java plugin support). How to move on for TW and Leap 42.3 is not decided yet I would say. For TW it's probably just temporary. One main reason blocking FF53 for TW currently is that FF53 also dropped i586 support which causes a technical issue with rust at the moment but also a policy one because TW is still supposed to support i586. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 26.04.2017 um 23:49 schrieb Roman Bysh:
I have been thinking about that. As it is today that also has some challenges: - from upstream there is no differentiation of names, config locations, OS integrations between latest and ESR; therefore the currently existing packages available on the buildservice are conflicting with each other. What is the overall expectation? Being able to have them installed in parallel and just choose from a launcher? Or is it ok to conflict? - officially a downgrade is not supported which means people can switch from ESR to latest with their profile quite fine. A switch back though is a risk Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 26 April 2017, Wolfgang Rosenauer wrote:
I would also really appreciate having ESR available.
Personally I need ESR only. Having both available would be nice for others probably. Parallel install could be even more nice (via update-alternatives). Though for me it's most important that ESR is available at all. So you may decide if you want to spend extra time to make parallel installation possible or just submit both ESR and non-ESR to Leap as they are now.
This is just the user's or admin's problem if they actively switch the default firefox. By default only one should be installed. I would vote for ESR being default on Leap. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday, 26 April 2017 18:08 Wolfgang Rosenauer wrote:
- Firefox requires rust mandatorily now to build https://bugzilla.opensuse.org/show_bug.cgi?id=1030232
And that is only where the problems start. I tried to build current Firefox mercurial snapshot on 42.2 and failed abysmally. It does not only need rust, it needs a very recent one (to quote their bug 1284816: "The latest stable distribution, not the latest git snapshot. Rust has a stable release every six weeks." - for suitable definition of "stable", sure). And it also requires gcc >= 4.9 while 42.2 has 4.8 as default. Normally, one would just set CC to gcc-5 and CXX to g++-5 but even then rust (I picked 1.6 from devel project) still complains that it cannot execute linker `cc`. At that point, I had to ask myself if it's still worth the hassle with the looming drop of the interface most extensions use. I don't know if they try to alienate both users and packagers on purpose or if they are just clueless but the result is the same. :-( Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 27.04.2017 um 07:25 schrieb Michal Kubecek:
Yes, I forgot the gcc requirement. And yes, it's not only rust but the upcoming stream of rust and toolchain updates which will be required. This was also discussed with our primary rust maintainer and the maintenance/release team but at least not deemed impossible. But certainly fun ahead.
I'm pretty sure they do not try to alienate us all. They try to stay relevant and some things blocking them to keep up with Chrome I'd say. And actually I would rather have a Mozilla browser being competitive and relevant than just Chrome/Chromium which in worst case brings us back to when Microsoft dominated the web but it certainly doesn't make our life easier. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Even worse....not sure about the privacy of Chrome. Google spys averything and everyone. As MS does these days as well in its 'operating system'. So having a browser alternative is vital.... Cheers Axel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Wolfgang Rosenauer wrote:
This is a highly welcome decision! I don't actually use Firefox a lot, but for me it is/was the ONLY way to use smartcard based electronic identification in Sweden. I don't think I'm the only one there, so a solution that offers ESR or 53+ via update-alternatives is (IMHO) mandatory... Pit -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2017-04-26 18:08, Wolfgang Rosenauer wrote:
A friend has asked me about Thunderbird: apparently upstream has v52, but we are on 45. Maybe it has already been explained on another post? I don't remember. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
Am 02.05.2017 um 15:49 schrieb Carlos E. R.:
Tumbleweed or Leap? For Tumbleweed an update to 52.0 was in the pipeline for two weeks now. I think one reason why it was delayed is a failing ppc64 build. (I do not even know if it was successful before.) For Leap we do not do version upgrades for the purpose of version upgrades. Version 52.0 did not bring any additional security fixes (which are the main and almost only reason for the version upgrades remember) compared to 45.latest. Thunderbird 52.1 which brings additional security fixes was released yesterday from upstream and is already submitted to Leap 42.1, 42.2 and Tumbleweed and waits for acceptance. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2017-05-02 at 16:24 +0200, Michael Ströder wrote:
Ring2 packages are not checked in if they break on ANY arch they are not explicitly setting as ExcludeArch. This currently means i586, x86_64 and ppc64le and work is going on to include s390x and aarch64 there. Experience shows that I DO get fixes for those archs if I block a checkin - once accepted, I can't get any maintainer to fix anything anymore and stuff just starts breaking ahead. And to answer the question 'if it built before': it certainly did - or ring2 would have been broken long ago. And to clear any other frustration: Mozilla Thunderbird 52.1.0 has been checked in and will be part of the upcoming 0503 snapshot. The submission was sr 492468 - created May 2nd 12:19 - checked in May 3rd 13:53 (all times UTC); so it seems upstream managed to get the fixes for ppc64le also into 52.1.0 and the 'issue' we had just disappeared with this update too... meaning we can deliver it. Cheers, Dominique
Am 03.05.2017 um 16:26 schrieb Dominique Leuenberger / DimStar:
We were discussing PPC64, not ppc64le. The review comments in 489303were talking about ppc64 instead.
For ppc64le the history was as follows: The submission of Thunderbird 52 on 2017-04-19 in 489303 was superseding a submission from the day before to fix ppc64le by submitting rev 364 from mozilla:Factory with the following changelog entry: ---------------------------------------------------------------------------- r364 | wrosenauer | 2017-04-19 09:45:54 | a03de8bb0ce2b4a834d68ecf2e2c199c | unknown | - require libffi explicitely to fix PPC64LE build where a system library is required This submission was done within 24 hours after the previous submission of version 52.0 which was commented to break ppc64le support. So if it's about ppc64le this was fixed pretty quickly after initial submission (within 24 hours) but then was waiting for "something" until 52.1.0 was submitted yesterday. Please note I'm not blaming anyone here because TB 52 was not that urgent to ship and I knew that 52.1.0 will follow soon enough. But it seems I need to correct the impression that I did not react on not building ppc64le for almost two weeks. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 2017-05-03 at 17:29 +0200, Wolfgang Rosenauer wrote:
We were discussing PPC64, not ppc64le. The review comments in 489303were talking about ppc64 instead.
Indeed - but that's a reviewer comment and the review team generally should not care for build fails (as there is no guarantee that what OBS shows as current build result is what has been submitted). The only authorative 'things' to judge on that are a) factory-repo-checker (only cares for i586 and x86_64, but expects those to build successful in the devel prj) b) Staging: where we build i586, x86_64 and ppc64le for everything up to ring1 and x86_64 and ppc64le for ring2 If you ever get blocked by the REVIEW team telling you stuff does not build in the devel project, feel free to send them away and have them trust the bots / staging personnel. Cheers, Dominique
On 02/05/17 10:44 AM, Carlos E. R. wrote:
Indeed: # zypper info MozillaFirefox Information for package MozillaFirefox: --------------------------------------- Repository: openSUSE BuildService - Mozilla Name: MozillaFirefox Version: 53.0-6.3 Arch: x86_64 Vendor: obs://build.opensuse.org/mozilla Installed: Yes Status: out-of-date (version 53.0-6.1 installed) Installed Size: 103.9 MiB Summary: Mozilla Firefox Web Browser "45" to "53" is a big step.
* Mon Apr 17 2017 wr@rosenauer.org - update to Firefox 53.0 ......... * Permission notifications have a cleaner design and cannot be easily missed * CVE-2017-5456 (bmo#1344415) Sandbox escape allowing local file system access * CVE-2017-5442 (bmo#1347979) Use-after-free during style changes * CVE-2017-5443 (bmo#1342661) Out-of-bounds write during BinHex decoding * CVE-2017-5429 (bmo#1341096, bmo#1342823, bmo#1343261, bmo#1348894, bmo#1348941, bmo#1349340, bmo#1350844, bmo#1352926, bmo#1353088) Memory safety bugs fixed in Firefox 53, Firefox ESR 45.9, and Firefox ESR 52.1 * CVE-2017-5464 (bmo#1347075) Memory corruption with accessibility and DOM manipulation * CVE-2017-5465 (bmo#1347617) Out-of-bounds read in ConvolvePixel * CVE-2017-5466 (bmo#1353975) Origin confusion when reloading isolated data:text/html URL * CVE-2017-5467 (bmo#1347262) Memory corruption when drawing Skia content * CVE-2017-5460 (bmo#1343642) Use-after-free in frame selection * CVE-2017-5461 (bmo#1344380) Out-of-bounds write in Base64 encoding in NSS * CVE-2017-5448 (bmo#1346648) Out-of-bounds write in ClearKeyDecryptor * CVE-2017-5449 (bmo#1340127) Crash during bidirectional unicode manipulation with animation * CVE-2017-5446 (bmo#1343505) Out-of-bounds read when HTTP/2 DATA frames are sent with incorrect data * CVE-2017-5447 (bmo#1343552) Out-of-bounds read during glyph processing * CVE-2017-5444 (bmo#1344461) Buffer overflow while parsing application/http-index-format content * CVE-2017-5445 (bmo#1344467) Uninitialized values used while parsing application/http-index-format content * CVE-2017-5468 (bmo#1329521) Incorrect ownership model for Private Browsing information * CVE-2017-5469 (bmo#1292534) Potential Buffer overflow in flex-generated code * CVE-2017-5440 (bmo#1336832) Use-after-free in txExecutionState destructor during XSLT processing * CVE-2017-5441 (bmo#1343795) Use-after-free with selection during scroll events * CVE-2017-5439 (bmo#1336830) Use-after-free in nsTArray Length() during XSLT processing * CVE-2017-5438 (bmo#1336828) Use-after-free in nsAutoPtr during XSLT processing * CVE-2017-5437 (bmo#1343453) Vulnerabilities in Libevent library * CVE-2017-5436 (bmo#1345461) Out-of-bounds write with malicious font in Graphite 2 * CVE-2017-5435 (bmo#1350683) Use-after-free during transaction processing in the editor * CVE-2017-5434 (bmo#1349946) Use-after-free during focus handling * CVE-2017-5433 (bmo#1347168) Use-after-free in SMIL animation functions * CVE-2017-5432 (bmo#1346654) Use-after-free in text input selection * CVE-2017-5430 (bmo#1329796, bmo#1337418, bmo#1339722, bmo#1340482, bmo#1342101, bmo#1344081, bmo#1344305, bmo#1344686, bmo#1346140, bmo#1346419, bmo#1348143, bmo#1349621, bmo#1349719, bmo#1353476) Memory safety bugs fixed in Firefox 53 and Firefox ESR 52.1 * CVE-2017-5459 (bmo#1333858) Buffer overflow in WebGL * CVE-2017-5458 (bmo#1229426) Drag and drop of javascript: URLs can allow for self-XSS * CVE-2017-5455 (bmo#1341191) Sandbox escape through internal feed reader APIs * CVE-2017-5454 (bmo#1349276) Sandbox escape allowing file system read access through file picker Correct me if I'm wrong but aren't those "CVE" things security issues ?
Thunderbird 52.1 which brings additional security fixes was released
Looking at "rpm -q --changelog MozillaFirefox" I see quite a few in * Sat Mar 04 2017 wr@rosenauer.org - update to Firefox 52.0 (boo#1028391) but not many in-between that and "53.0" -- "There are two primary choices in life: to accept conditions as they exist, or accept the responsibility for changing them". -- Denis Waitley. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 03.05.2017 um 14:24 schrieb Anton Aylward:
did you now switch intentionally from Thunderbird to Firefox? If so let us discuss Firefox and do not comment on my Thunderbird explanations with Firefox counter examples please. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2017-05-03 18:18, Anton Aylward wrote:
Yes, but I took the opportunity to ask about Thunderbird, because it is related, it has the same maintainer, and the reason for the update or not could be similar. I failed to change the subject line, but the text in the post was clear enough. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 03/05/17 02:00 PM, Carlos E. R. wrote:
And the version numbers on each, at least on my system, are similar. Before that last update I made to Firefox yesterday they were both 52.<something> on my system Coincidence?
I failed to change the subject line, but the text in the post was clear enough.
Perhaps I should have chosen an item earlier in the thread before you changed the ${BODY}-subject away from the ${SUBJ), that is, staying on topic. This is a pointless sub-argument. The core issue about the updates, the upstream, applies to both. As you say, its related, and, while not sharing as much of the code as eternal libraries as I would like to see, does have an amazingly common code base, and hence the vulnerability in one are very likely to be in the other, and 'fixed/'maintained' in the same way, around the same time. That, however, is not enough reason, as far as I can see, for the similar numbering. Others may disagree. -- The scars of others should teach us caution. -- Saint Jerome, Letter -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Wolfgang Rosenauer composed on 2017-04-26 18:08 (UTC+0200):
...One main reason blocking FF53 for TW currently is that FF53 also dropped i586 support...
Do you have an upstream bug for this? I can't find one, only from https://www.mozilla.org/en-US/firefox/53.0/releasenotes/ : 1-WinXP and Vista support were dropped. 2-32-bit Mac OS X is no longer supported 3-Ended Firefox Linux support for processors older than Pentium 4 and AMD Opteron #3 I thought means SSE2 required, not 32-bit dropped. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 25.07.2017 um 09:21 schrieb Felix Miata:
You are right but I was also right. I didn't write 32-bit support dropped but i586 dropped, _not_ i686. But our TW is i586 and not i686 in general. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (12)
-
Anton Aylward -
Axel Braun -
cagsm -
Carlos E. R. -
Dominique Leuenberger / DimStar -
Felix Miata -
Michael Ströder -
Michal Kubecek -
Peter Suetterlin -
Roman Bysh -
Ruediger Meier -
Wolfgang Rosenauer