Mandriva has issued an advisory on June 9: http://www.mandriva.com/en/support/security/advisories/?dis=2011&name=MDVSA-2012:088 This bug will be for the Mageia 2 update.
Blocks: (none) => 6389
Updates ready for testing. Source RPM list at the bottom of this post, I'll gather up the full RPM list later. Note to QA: Mandriva has rebuilt icedtea-web for this update and we haven't. Please test that icedtea-web still works fine. If there are any problems, I'll submit a rebuild for it. Advisory: ======================== Updated firefox packages fix security vulnerabilities: Heap-based buffer overflow in the utf16_to_isolatin1 function in Mozilla Firefox 4.x through 12.0, Firefox ESR 10.x before 10.0.5, Thunderbird 5.0 through 12.0, Thunderbird ESR 10.x before 10.0.5, and SeaMonkey before 2.10 allows remote attackers to execute arbitrary code via vectors that trigger a character-set conversion failure (CVE-2012-1947) Use-after-free vulnerability in the nsFrameList::FirstChild function in Mozilla Firefox 4.x through 12.0, Firefox ESR 10.x before 10.0.5, Thunderbird 5.0 through 12.0, Thunderbird ESR 10.x before 10.0.5, and SeaMonkey before 2.10 allows remote attackers to execute arbitrary code or cause a denial of service (heap memory corruption and application crash) by changing the size of a container of absolutely positioned elements in a column (CVE-2012-1940). Heap-based buffer overflow in the nsHTMLReflowState::CalculateHypotheticalBox function in Mozilla Firefox 4.x through 12.0, Firefox ESR 10.x before 10.0.5, Thunderbird 5.0 through 12.0, Thunderbird ESR 10.x before 10.0.5, and SeaMonkey before 2.10 allows remote attackers to execute arbitrary code by resizing a window displaying absolutely positioned and relatively positioned elements in nested columns (CVE-2012-1941). Use-after-free vulnerability in the nsINode::ReplaceOrInsertBefore function in Mozilla Firefox 4.x through 12.0, Firefox ESR 10.x before 10.0.5, Thunderbird 5.0 through 12.0, Thunderbird ESR 10.x before 10.0.5, and SeaMonkey before 2.10 might allow remote attackers to execute arbitrary code via document changes involving replacement or insertion of a node (CVE-2012-1946). Mozilla Firefox 4.x through 12.0, Firefox ESR 10.x before 10.0.5, Thunderbird 5.0 through 12.0, Thunderbird ESR 10.x before 10.0.5, and SeaMonkey before 2.10 allow local users to obtain sensitive information via an HTML document that loads a shortcut (aka .lnk) file for display within an IFRAME element, as demonstrated by a network share implemented by (1) Microsoft Windows or (2) Samba (CVE-2012-1945). The Content Security Policy (CSP) implementation in Mozilla Firefox 4.x through 12.0, Firefox ESR 10.x before 10.0.5, Thunderbird 5.0 through 12.0, Thunderbird ESR 10.x before 10.0.5, and SeaMonkey before 2.10 does not block inline event handlers, which makes it easier for remote attackers to conduct cross-site scripting (XSS) attacks via a crafted HTML document (CVE-2012-1944). Multiple unspecified vulnerabilities in the browser engine in Mozilla Firefox before 13.0, Thunderbird before 13.0, and SeaMonkey before 2.10 allow remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via vectors related to (1) methodjit/ImmutableSync.cpp, (2) the JSObject::makeDenseArraySlow function in js/src/jsarray.cpp, and unknown other components (CVE-2012-1938). jsinfer.cpp in Mozilla Firefox ESR 10.x before 10.0.5 and Thunderbird ESR 10.x before 10.0.5 does not properly determine data types, which allows remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via crafted JavaScript code (CVE-2012-1939). Multiple unspecified vulnerabilities in the browser engine in Mozilla Firefox 4.x through 12.0, Firefox ESR 10.x before 10.0.5, Thunderbird 5.0 through 12.0, Thunderbird ESR 10.x before 10.0.5, and SeaMonkey before 2.10 allow remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via unknown vectors (CVE-2012-1937). Ken Russell of Google reported a bug in NVIDIA graphics drivers that they needed to work around in the Chromium WebGL implementation. Mozilla has done the same in Firefox 13 and ESR 10.0.5 (CVE-2011-3101). Additionally, the nspr and nss libraries have been upgraded to the latest versions which resolve various upstream bugs. Also, gnome-python-gtkmozembed has been rebuilt against the updated xulrunner library. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3101 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1937 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1938 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1939 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1940 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1941 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1944 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1945 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1946 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1947 http://www.mozilla.org/security/announce/2012/mfsa2012-34.html http://www.mozilla.org/security/announce/2012/mfsa2012-36.html http://www.mozilla.org/security/announce/2012/mfsa2012-37.html http://www.mozilla.org/security/announce/2012/mfsa2012-38.html http://www.mozilla.org/security/announce/2012/mfsa2012-40.html http://www.mandriva.com/en/support/security/advisories/?dis=2010.1&name=MDVSA-2012:088-1 ======================== Source RPMs: nspr-4.9.1-1.mga2.src.rpm nss-3.13.5-1.mga2.src.rpm xulrunner-10.0.5-1.1.mga2.src.rpm firefox-10.0.5-1.mga2.src.rpm firefox-l10n-10.0.5-1.1.mga2.src.rpm gnome-python-extras-2.25.3-38.1.mga2
Assignee: bugsquad => qa-bugs
Full RPM list: libnspr4-4.9.1-1.mga2 libnspr-devel-4.9.1-1.mga2 nss-3.13.5-1.mga2 nss-doc-3.13.5-1.mga2 libnss3-3.13.5-1.mga2 libnss-devel-3.13.5-1.mga2 libnss-static-devel-3.13.5-1.mga2 xulrunner-10.0.5-1.1.mga2 libxulrunner10.0.5-10.0.5-1.1.mga2 libxulrunner-devel-10.0.5-1.1.mga2 firefox-10.0.5-1.mga2 firefox-devel-10.0.5-1.mga2 firefox-af-10.0.5-1.1.mga2 firefox-ar-10.0.5-1.1.mga2 firefox-ast-10.0.5-1.1.mga2 firefox-be-10.0.5-1.1.mga2 firefox-bg-10.0.5-1.1.mga2 firefox-bn_BD-10.0.5-1.1.mga2 firefox-bn_IN-10.0.5-1.1.mga2 firefox-br-10.0.5-1.1.mga2 firefox-bs-10.0.5-1.1.mga2 firefox-ca-10.0.5-1.1.mga2 firefox-cs-10.0.5-1.1.mga2 firefox-cy-10.0.5-1.1.mga2 firefox-da-10.0.5-1.1.mga2 firefox-de-10.0.5-1.1.mga2 firefox-el-10.0.5-1.1.mga2 firefox-en_GB-10.0.5-1.1.mga2 firefox-en_ZA-10.0.5-1.1.mga2 firefox-eo-10.0.5-1.1.mga2 firefox-es_AR-10.0.5-1.1.mga2 firefox-es_CL-10.0.5-1.1.mga2 firefox-es_ES-10.0.5-1.1.mga2 firefox-es_MX-10.0.5-1.1.mga2 firefox-et-10.0.5-1.1.mga2 firefox-eu-10.0.5-1.1.mga2 firefox-fa-10.0.5-1.1.mga2 firefox-fi-10.0.5-1.1.mga2 firefox-fr-10.0.5-1.1.mga2 firefox-fy-10.0.5-1.1.mga2 firefox-ga_IE-10.0.5-1.1.mga2 firefox-gd-10.0.5-1.1.mga2 firefox-gl-10.0.5-1.1.mga2 firefox-gu_IN-10.0.5-1.1.mga2 firefox-he-10.0.5-1.1.mga2 firefox-hi-10.0.5-1.1.mga2 firefox-hr-10.0.5-1.1.mga2 firefox-hu-10.0.5-1.1.mga2 firefox-hy-10.0.5-1.1.mga2 firefox-id-10.0.5-1.1.mga2 firefox-is-10.0.5-1.1.mga2 firefox-it-10.0.5-1.1.mga2 firefox-ja-10.0.5-1.1.mga2 firefox-kk-10.0.5-1.1.mga2 firefox-kn-10.0.5-1.1.mga2 firefox-ko-10.0.5-1.1.mga2 firefox-ku-10.0.5-1.1.mga2 firefox-lg-10.0.5-1.1.mga2 firefox-lt-10.0.5-1.1.mga2 firefox-lv-10.0.5-1.1.mga2 firefox-mai-10.0.5-1.1.mga2 firefox-mk-10.0.5-1.1.mga2 firefox-ml-10.0.5-1.1.mga2 firefox-mr-10.0.5-1.1.mga2 firefox-nb_NO-10.0.5-1.1.mga2 firefox-nl-10.0.5-1.1.mga2 firefox-nn_NO-10.0.5-1.1.mga2 firefox-nso-10.0.5-1.1.mga2 firefox-or-10.0.5-1.1.mga2 firefox-pa_IN-10.0.5-1.1.mga2 firefox-pl-10.0.5-1.1.mga2 firefox-pt_BR-10.0.5-1.1.mga2 firefox-pt_PT-10.0.5-1.1.mga2 firefox-ro-10.0.5-1.1.mga2 firefox-ru-10.0.5-1.1.mga2 firefox-si-10.0.5-1.1.mga2 firefox-sk-10.0.5-1.1.mga2 firefox-sl-10.0.5-1.1.mga2 firefox-sq-10.0.5-1.1.mga2 firefox-sr-10.0.5-1.1.mga2 firefox-sv_SE-10.0.5-1.1.mga2 firefox-ta-10.0.5-1.1.mga2 firefox-ta_LK-10.0.5-1.1.mga2 firefox-te-10.0.5-1.1.mga2 firefox-th-10.0.5-1.1.mga2 firefox-tr-10.0.5-1.1.mga2 firefox-uk-10.0.5-1.1.mga2 firefox-vi-10.0.5-1.1.mga2 firefox-zh_CN-10.0.5-1.1.mga2 firefox-zh_TW-10.0.5-1.1.mga2 firefox-zu-10.0.5-1.1.mga2 gnome-python-extras-2.25.3-38.1.mga2 gnome-python-gda-2.25.3-38.1.mga2 gnome-python-gda-devel-2.25.3-38.1.mga2 gnome-python-gtkspell-2.25.3-38.1.mga2 gnome-python-gtkmozembed-2.25.3-38.1.mga2 gnome-python-gtkhtml2-2.25.3-38.1.mga2
Testing on i586, MGA2. There are either no public PoC's or Firefox 10 ESR doesn't seem to be affected. So testing for regressions only...
CC: (none) => wassi
Testing complete on i586, MGA2. Tested several random websites as well as the top 7 listed here: http://www.alexa.com/topsites Also tested several java applets - everything worked. Bookmarks stayed in place, addons all work. Source RPMs: firefox-10.0.5-1.mga2.src.rpm firefox-l10n-10.0.5-1.1.mga2.src.rpm gnome-python-extras-2.25.3-38.1.mga2 nspr-4.9.1-1.mga2.src.rpm nss-3.13.5-1.mga2.src.rpm xulrunner-10.0.5-1.1.mga2.src.rpm
Whiteboard: (none) => MGA2-32-OK
Tested x86_64 and i586 Tested https, java, flash, l10n all OK No regressions noticed. For gnome-python-extras testing gnome-python-gtkmozembed with the example here: http://www.pygtk.org/pygtkmozembed/class-gtkmozembed.html I have not managed to make it work, before or after the update. $ python gtkmozembed.py ** (process:5032): WARNING **: Trying to register gtype 'GMountMountFlags' as enum when in fact it is of type 'GFlags' ** (process:5032): WARNING **: Trying to register gtype 'GDriveStartFlags' as enum when in fact it is of type 'GFlags' ** (process:5032): WARNING **: Trying to register gtype 'GSocketMsgFlags' as enum when in fact it is of type 'GFlags' Traceback (most recent call last): File "gtkmozembed.py", line 16, in <module> TinyGecko() File "gtkmozembed.py", line 6, in __init__ self.moz = gtkmozembed.MozEmbed() AttributeError: 'module' object has no attribute 'MozEmbed' $ python >>> dir(gtkmozembed) ['TinyGecko', '__builtins__', '__doc__', '__file__', '__name__', '__package__', 'gtk', 'gtkmozembed'] I'll try rebooting in case it is some environment variable not properly set.
Same after a reboot, so not a regression but apparently not working either. Am I doing something wrong? firefox-10.0.5-1.mga2 firefox-en_GB-10.0.5-1.1.mga2 firefox-en_ZA-10.0.5-1.1.mga2 gnome-python-extras-2.25.3-38.1.mga2 gnome-python-gtkmozembed-2.25.3-38.1.mga2 gnome-python-gtkspell-2.25.3-38.1.mga2 lib64nspr4-4.9.1-1.mga2 lib64nss3-3.13.5-1.mga2 lib64xulrunner10.0.5-10.0.5-1.1.mga2 nss-3.13.5-1.mga2 xulrunner-10.0.5-1.1.mga2
Have the lists here changed David or do others still need to be rebuilt? https://wiki.mageia.org/en/Updates/Firefox
(In reply to comment #7) > Have the lists here changed David or do others still need to be rebuilt? > > https://wiki.mageia.org/en/Updates/Firefox The wiki page is incorrect. Please disregard it.
then update it please.
CC: (none) => dmorganec
(In reply to comment #6) > Am I doing something wrong? Probably, as I can't reproduce and my dir(gtkmozembed) output doesn't match yours. If you have done this in a saved something.py file (rather than trying it in the interactive interpreter), make sure of two things: 1) don't name your python file gtkmozembed.py 2) make sure you have "import gtkmozembed" at the beginning as the example shows.
(In reply to comment #9) > then update it please. I'd rather just delete it, but I don't think Wikis allow that.
this is just non sense to remove it. We need to help people in QA. So what is wrong in it ? so I will fix
(In reply to comment #12) > this is just non sense to remove it. We need to help people in QA. > > > So what is wrong in it ? so I will fix OK, you can use this for a basis for updating it. When the firefox package is updated, the following things should happen as well: - The nspr and nss packages should be updated to the latest version - The xulrunner package should also be updated - Packages dependent on the exact current version of the xulrunner library should be rebuilt. For example, if the current version is libxulrunner10.0.4, the command "urpmq --whatrequires libxulrunner10.0.4" should give you the list. On Mageia 1, this list currently includes: - perl-Gtk-MozEmbed - gnome-python-gtkmozembed (from the gnome-python-extras SRPM) - libgjs0 (from the gjs SRPM) - eclipse-swt (from the eclipse SRPM) Currently gjs and eclipse can't be rebuilt against current versions of xulrunner without being updated to a newer version that supports the current API. Bug 6382 has been filed for gjs. On Mageia 2, this list currently includes: - gnome-python-gtkmozembed (from the gnome-python-extras SRPM) Finally, if Firefox is being upgraded to a new major version, Firefox extension packages should be rebuilt as well.
(In reply to comment #13) > OK, you can use this for a basis for updating it. > > When the firefox package is updated, the following things should happen as > well: > - The nspr and nss packages should be updated to the latest version Why? (if there are no security problems of course). > Finally, if Firefox is being upgraded to a new major version, Firefox extension > packages should be rebuilt as well. Again, why?
CC: (none) => sander.lepik
Well spotted! Renaming my test file indeed made all the difference. I really should learn some python. Sadly I now get a segfault from it instead. $ python moz.py ** (process:7640): WARNING **: Trying to register gtype 'GMountMountFlags' as enum when in fact it is of type 'GFlags' ** (process:7640): WARNING **: Trying to register gtype 'GDriveStartFlags' as enum when in fact it is of type 'GFlags' ** (process:7640): WARNING **: Trying to register gtype 'GSocketMsgFlags' as enum when in fact it is of type 'GFlags' Segmentation fault syslog says: kernel: [ 4909.279373] python[7688]: segfault at 0 ip 00007f5d881df6f7 sp 00007fffbca28890 error 4 in libxul.so[7f5d87c0e000+19d3000] $ rpm -qa | grep lib64xulrunner lib64xulrunner10.0.5-10.0.5-1.1.mga2 Verified eclipse-swt works ok anyway.
(In reply to comment #14) > (In reply to comment #13) > > OK, you can use this for a basis for updating it. > > > > When the firefox package is updated, the following things should happen as > > well: > > - The nspr and nss packages should be updated to the latest version > > Why? (if there are no security problems of course). nspr and nss are part of Firefox. If you get a FF binary on another platform, they are built in and updated. The updates contain bugfixes. According to Stew Benedict, upstream promised (probably for LSB) that they won't break binary compatibility, so they should be safe to update. Bugs fixed in the upstream release announcements for FF include bugs fixed in nspr and nss. Even for 10.0.5, one of the security bugs upstream said was fixed was actually fixed in nss. These should be kept up to date. > > Finally, if Firefox is being upgraded to a new major version, Firefox extension > > packages should be rebuilt as well. > > Again, why? Haha, lots of people have been asking that for quite some time. I don't know. Thank goodness for Firefox ESR that we don't have to worry about it as much anymore. Firefox extensions for other platforms *usually* don't need rebuilt, although the upgrade process from FF3->FF10 did cause a lot of compatibility problems. Going back to Mandriva times, our extension packages usually have a hard requires on the current Firefox version, which is why they end up needing rebuilt. I never saw the justification for it, so I'm just documenting it here.
(In reply to comment #15) > Well spotted! Renaming my test file indeed made all the difference. I really > should learn some python. Sadly I now get a segfault from it instead. > > $ python moz.py > > ** (process:7640): WARNING **: Trying to register gtype 'GMountMountFlags' as > enum when in fact it is of type 'GFlags' > > ** (process:7640): WARNING **: Trying to register gtype 'GDriveStartFlags' as > enum when in fact it is of type 'GFlags' > > ** (process:7640): WARNING **: Trying to register gtype 'GSocketMsgFlags' as > enum when in fact it is of type 'GFlags' > Segmentation fault > > > syslog says: > kernel: [ 4909.279373] python[7688]: segfault at 0 ip 00007f5d881df6f7 sp > 00007fffbca28890 error 4 in libxul.so[7f5d87c0e000+19d3000] Pascal, do you have any idea what this is about?
CC: (none) => pterjan
(In reply to comment #16) > Haha, lots of people have been asking that for quite some time. I don't know. > Thank goodness for Firefox ESR that we don't have to worry about it as much > anymore. Firefox extensions for other platforms *usually* don't need rebuilt, > although the upgrade process from FF3->FF10 did cause a lot of compatibility > problems. Going back to Mandriva times, our extension packages usually have a > hard requires on the current Firefox version, which is why they end up needing > rebuilt. I never saw the justification for it, so I'm just documenting it > here. Since some version of Firefox (don't remember which one) this is not needed anymore. Extension that is compatible with fx4.0 will stay enabled. It will be disabled if during beta testing some problems will come up. And it only needs a rebuild if it's binary extension. Don't know how many we have those.
(In reply to comment #18) > (In reply to comment #16) > > Haha, lots of people have been asking that for quite some time. I don't know. > > Thank goodness for Firefox ESR that we don't have to worry about it as much > > anymore. Firefox extensions for other platforms *usually* don't need rebuilt, > > although the upgrade process from FF3->FF10 did cause a lot of compatibility > > problems. Going back to Mandriva times, our extension packages usually have a > > hard requires on the current Firefox version, which is why they end up needing > > rebuilt. I never saw the justification for it, so I'm just documenting it > > here. > > Since some version of Firefox (don't remember which one) this is not needed > anymore. Extension that is compatible with fx4.0 will stay enabled. It will be > disabled if during beta testing some problems will come up. And it only needs a > rebuild if it's binary extension. Don't know how many we have those. Thanks Sander, this is helpful. Is there an easy way to determine which ones are binary? I guess non-binary means it's just written in XUL or something? Anyway, if you see any extension packages in Cauldron that still have a hard requires on the Firefox version and shouldn't, feel free to complain so they can be fixed.
(In reply to comment #19) > Thanks Sander, this is helpful. Is there an easy way to determine which ones > are binary? Well, if it's noarch then it's not :)
(In reply to comment #15) > Verified eclipse-swt works ok anyway. Just to be clear, the only way to truly verify this is to try an SWT program that uses the Browser widget, as I discussed with Dave in and around this comment in a previous FF update: https://bugs.mageia.org/show_bug.cgi?id=4405#c21
I used the tutorial for swt built in to eclipse. It opened a window titled Hello World.
I'll have another go with the one from your link if it's needed? http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/examples/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet148.java Or are we sure?
(In reply to comment #23) > I'll have another go with the one from your link if it's needed? > > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/examples/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet148.java > > Or are we sure? If you want to test it with regard to its xulrunner linkage, something using the Browser widget (such as that snippet) needs to be tested. A simple Hello World example doesn't use xulrunner and wouldn't break even if the FF update was broken. We haven't rebuilt eclipse-swt for this update, but you can try to test that snippet if you want to make sure it's OK to not rebuild it (just make sure you don't still have libxulrunner10.0.4 installed).
Built the example after sorting out the required bits at the top. https://dl.dropbox.com/u/4147101/QA/firefox.jar You should be able to run it with java -jar firefox.jar
Testing complete for the srpm firefox-10.0.5-1.mga2.src.rpm on Mageia release 2 (Official) for x86_64 ,for me it works fine. -firefox -firefox-fr
CC: (none) => geiger.david68210
iinm building/running the java snippet with eclipse-swt also tests xulrunner so I think its safe to say testing is now complete x86_64 Mageia 2. Removing the mga2-32-OK whiteboard keyword as I don't think gnome-python-gtkmozembed or xulrunner have been tested i586 yet. Please correct if I'm wrong :) This can be validated when these have been checked.
Whiteboard: MGA2-32-OK => mga2-64-OK
Testing xulrunner i586. I'm writing a howto for the wiki too.
gnome-python-gtkmozembed hast been tested on i586, MGA2, using the sample from http://www.pygtk.org/pygtkmozembed/class-gtkmozembed.html. (Although I admit I did so only after I saw Claires comment, I didn't previously think this was needed. However I do actively follow the bug and would have removed the keyword if I felt this was appropriate). The sample crashed the python process (same as in Comment 15), however I got the exact same problem before and after updating, so this is not a regression. xulrunner has not been tested, as I thought it is used by firefox to render its UI. Therefore I didn't test seperately. Thanks for doing that, Claire!
So just to recap. I think I was getting ahead of myself validating.. Building the java snippet in eclipse-swt tests xulrunner. I'll complete that i586 in the morning if nobody beats me to it. There is still a problem with lib(64)xulrunner segfaults but it doesn't appear to be a regression. I didn't yet check with 10.0.4 on x86_64 to confirm that it isn't a regression. The segfaults occur when testing python-gtkmozembed kernel: [ 2090.938264] python[6794]: segfault at 0 ip 00007fd93dba76f7 sp 00007fff7dae7300 error 4 in libxul.so[7fd93d5d6000+19d3000] What do you want to do about these David?
(In reply to comment #30) > The segfaults occur when testing python-gtkmozembed > > kernel: [ 2090.938264] python[6794]: segfault at 0 ip 00007fd93dba76f7 sp > 00007fff7dae7300 error 4 in libxul.so[7fd93d5d6000+19d3000] > > What do you want to do about these David? I'm hoping to get a response from Pascal Terjan, as he committed the fixes to Firefox to allow this package to build. D Morgan, Jani Välimaa, and Funda Wang have worked with the gnome-python-extras package in the past as well, so I'll CC them.
CC: (none) => jani.valimaa
CC: (none) => fundawang
(In reply to comment #31) > (In reply to comment #30) > > The segfaults occur when testing python-gtkmozembed > > > > kernel: [ 2090.938264] python[6794]: segfault at 0 ip 00007fd93dba76f7 sp > > 00007fff7dae7300 error 4 in libxul.so[7fd93d5d6000+19d3000] > > > > What do you want to do about these David? > > I'm hoping to get a response from Pascal Terjan, as he committed the fixes to > Firefox to allow this package to build. D Morgan, Jani Välimaa, and Funda Wang > have worked with the gnome-python-extras package in the past as well, so I'll > CC them. Also, if this is not a regression, we should probably just file a new bug for it, exclude gnome-python-extras from this update, and move on for now.
I'm having problems i586 with the xulrunner snippet in eclipse with eclipse-swt. It opens a window but no browser inside the window. I've tried several times now. Perhaps somebody else could try in case I am doing something wrong. I'll revert back to 10.0.4 and see if the same thing happens.
After speaking with fedora eclipse maitainer i have rebuilded eclipse w/o xulrunner support as it doesn't build + doesn't work ( mainly crashes ). so you can try eclipse to test it still works OK and then validate for eclipse on this udpate + no rebuild of eclipse will be needed in the future in mga1
i will do the same on mga2 in about an hour
package is now available in mga2 too
Thankyou for doing that dmorgan. Is the same test appropriate or is that functionality disabled now? I think I'm right in saying that what is holding this back now is libxulrunner10.0.5 where it affects gnome-python-gtkmozembed (and perl-Gtk2-MozEmbed in mga1 bug 6389) but that is not a regression and may have been segfaulting since 2008. What should be done with that? Should we validate and handle that separately, given this is a firefox security update?
Should firefox be separated from the xulrunner/libxulrunner packages maybe?
this is already done. Firefox doesn't need xulrunned anymore. xulrunner is only needed by other apps.
So if we check eclipse still works we can validate at least nspr-4.9.1-1.mga2.src.rpm nss-3.13.5-1.mga2.src.rpm firefox-10.0.5-1.mga2.src.rpm firefox-l10n-10.0.5-1.1.mga2.src.rpm and the updated eclipse at the same time eclipse-3.7.1-3.1.mga2.src.rpm I'll create a new bug for xulrunner-10.0.5-1.1.mga2.src.rpm What about.. gnome-python-extras-2.25.3-38.1.mga2.src.rpm ?
seems good. what about gnome-python-extras ?
(In reply to comment #41) > what about gnome-python-extras ? It's broken, as is perl-Gtk-MozEmbed in Mageia 1. Can they be fixed? If not, there's no point including them in the updates.
gnome-python-gtkmozembed really. libxul.so.0 segfaults - see comment 15 Also on mageia 1 (bug 6389) same thing but perl-Gtk2-MozEmbed also. I guess both of those belong with the new xulrunner bug I've not yet created?
(In reply to comment #43) > gnome-python-gtkmozembed really. libxul.so.0 segfaults - see comment 15 > > Also on mageia 1 (bug 6389) same thing but perl-Gtk2-MozEmbed also. > > I guess both of those belong with the new xulrunner bug I've not yet created? Yep. Also, when you tested the Browser widget SWT snippet for eclipse earlier, did it work? If so, for what purpose has eclipse now been rebuilt?
Testing eclipse x86_64 Tested the firefox project I used in comment 23 and 25 installed the update. The following 6 packages are going to be installed: - eclipse-equinox-osgi-3.7.1-3.1.mga2.x86_64 - eclipse-jdt-3.7.1-3.1.mga2.x86_64 - eclipse-pde-3.7.1-3.1.mga2.x86_64 - eclipse-platform-3.7.1-3.1.mga2.x86_64 - eclipse-rcp-3.7.1-3.1.mga2.x86_64 - eclipse-swt-3.7.1-3.1.mga2.x86_64 When I restarted eclipse the Project Explorer had closed and the code panel shows an error, not sure if this is just because it is missing xulrunner.. Could not open the editor: No editor descriptor for id org.eclipse.jdt.ui.CompilationUnitEditor org.eclipse.ui.PartInitException: No editor descriptor for id org.eclipse.jdt.ui.CompilationUnitEditor at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:601) at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:465) at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:595) at org.eclipse.ui.internal.EditorAreaHelper.setVisibleEditor(EditorAreaHelper.java:271) at org.eclipse.ui.internal.EditorManager.setVisibleEditor(EditorManager.java:1459) at org.eclipse.ui.internal.EditorManager$5.runWithException(EditorManager.java:972) at org.eclipse.ui.internal.StartupThreading$StartupRunnable.run(StartupThreading.java:31) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3563) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3212) at org.eclipse.ui.application.WorkbenchAdvisor.openWindows(WorkbenchAdvisor.java:803) at org.eclipse.ui.internal.Workbench$33.runWithException(Workbench.java:1595) at org.eclipse.ui.internal.StartupThreading$StartupRunnable.run(StartupThreading.java:31) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3563) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3212) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2604) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2494) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577) at org.eclipse.equinox.launcher.Main.run(Main.java:1410) at org.eclipse.equinox.launcher.Main.main(Main.java:1386)
Yes, it worked David, see comment 25
Perhaps eclipse should have it's own bug?
(In reply to comment #47) > Perhaps eclipse should have it's own bug? Yes, I think so. Something does need to happen with it in Mageia 1, because it's still using an old xulrunner. If it works already in Mageia 2 without rebuilding it (and making sure only the updated xulrunner library is installed), I don't see a need to do anything to it.
It does seem to David, at least x86_64. I didn't get it to work properly i586. I think that may be why the rebuild, to drop xulrunner, hence it now complaining above. I'll try the hello world swt tutorial with the update but we should be certain before validating anything.
what do you mean ? in mga1 Firefox doesn't need xulrunner neither
(In reply to comment #50) > what do you mean ? in mga1 Firefox doesn't need xulrunner neither What is that in response to? If it's Comment 49, she was talking about eclipse-swt, not firefox.
CC: jani.valimaa => (none)
There seems to be a problem with the eclipse update anyway, 'New' no longer has the option for 'New Java Project'. I think we should handle the updates eclipse separately. So, if we do that and I create a new bug for the xulrunner (gnome-python-gtkmozembed & perl-Gtk-MozEmbed) problem are we in a position to validate this?
yes please open a bugreport for eclipse but don't block the update for this.
David would you handle the eclipse update please. I'll create a BR for xulrunner and then validate this one
Bug 6610 created for xulrunner
(In reply to comment #54) > David would you handle the eclipse update please. Bug 6611 filed for eclipse. > I'll create a BR for xulrunner and then validate this one Thanks. Be sure to remove the last sentence about gnome-python-gtkmozembed from the advisory :o) Oh, also before you validate this, did anyone test to verify that icedtea-web still works with the updated Firefox?
Java, flash, https etc all ok David yes. Please check this is correct for me. I left the gnome-python-extras and xulrunner srpm's off. Can either be removed from testing? If correct I'll validate with it. Advisory: ======================== Updated firefox packages fix security vulnerabilities: Heap-based buffer overflow in the utf16_to_isolatin1 function in Mozilla Firefox 4.x through 12.0, Firefox ESR 10.x before 10.0.5, Thunderbird 5.0 through 12.0, Thunderbird ESR 10.x before 10.0.5, and SeaMonkey before 2.10 allows remote attackers to execute arbitrary code via vectors that trigger a character-set conversion failure (CVE-2012-1947) Use-after-free vulnerability in the nsFrameList::FirstChild function in Mozilla Firefox 4.x through 12.0, Firefox ESR 10.x before 10.0.5, Thunderbird 5.0 through 12.0, Thunderbird ESR 10.x before 10.0.5, and SeaMonkey before 2.10 allows remote attackers to execute arbitrary code or cause a denial of service (heap memory corruption and application crash) by changing the size of a container of absolutely positioned elements in a column (CVE-2012-1940). Heap-based buffer overflow in the nsHTMLReflowState::CalculateHypotheticalBox function in Mozilla Firefox 4.x through 12.0, Firefox ESR 10.x before 10.0.5, Thunderbird 5.0 through 12.0, Thunderbird ESR 10.x before 10.0.5, and SeaMonkey before 2.10 allows remote attackers to execute arbitrary code by resizing a window displaying absolutely positioned and relatively positioned elements in nested columns (CVE-2012-1941). Use-after-free vulnerability in the nsINode::ReplaceOrInsertBefore function in Mozilla Firefox 4.x through 12.0, Firefox ESR 10.x before 10.0.5, Thunderbird 5.0 through 12.0, Thunderbird ESR 10.x before 10.0.5, and SeaMonkey before 2.10 might allow remote attackers to execute arbitrary code via document changes involving replacement or insertion of a node (CVE-2012-1946). Mozilla Firefox 4.x through 12.0, Firefox ESR 10.x before 10.0.5, Thunderbird 5.0 through 12.0, Thunderbird ESR 10.x before 10.0.5, and SeaMonkey before 2.10 allow local users to obtain sensitive information via an HTML document that loads a shortcut (aka .lnk) file for display within an IFRAME element, as demonstrated by a network share implemented by (1) Microsoft Windows or (2) Samba (CVE-2012-1945). The Content Security Policy (CSP) implementation in Mozilla Firefox 4.x through 12.0, Firefox ESR 10.x before 10.0.5, Thunderbird 5.0 through 12.0, Thunderbird ESR 10.x before 10.0.5, and SeaMonkey before 2.10 does not block inline event handlers, which makes it easier for remote attackers to conduct cross-site scripting (XSS) attacks via a crafted HTML document (CVE-2012-1944). Multiple unspecified vulnerabilities in the browser engine in Mozilla Firefox before 13.0, Thunderbird before 13.0, and SeaMonkey before 2.10 allow remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via vectors related to (1) methodjit/ImmutableSync.cpp, (2) the JSObject::makeDenseArraySlow function in js/src/jsarray.cpp, and unknown other components (CVE-2012-1938). jsinfer.cpp in Mozilla Firefox ESR 10.x before 10.0.5 and Thunderbird ESR 10.x before 10.0.5 does not properly determine data types, which allows remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via crafted JavaScript code (CVE-2012-1939). Multiple unspecified vulnerabilities in the browser engine in Mozilla Firefox 4.x through 12.0, Firefox ESR 10.x before 10.0.5, Thunderbird 5.0 through 12.0, Thunderbird ESR 10.x before 10.0.5, and SeaMonkey before 2.10 allow remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via unknown vectors (CVE-2012-1937). Ken Russell of Google reported a bug in NVIDIA graphics drivers that they needed to work around in the Chromium WebGL implementation. Mozilla has done the same in Firefox 13 and ESR 10.0.5 (CVE-2011-3101). Additionally, the nspr and nss libraries have been upgraded to the latest versions which resolve various upstream bugs. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3101 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1937 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1938 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1939 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1940 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1941 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1944 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1945 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1946 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1947 http://www.mozilla.org/security/announce/2012/mfsa2012-34.html http://www.mozilla.org/security/announce/2012/mfsa2012-36.html http://www.mozilla.org/security/announce/2012/mfsa2012-37.html http://www.mozilla.org/security/announce/2012/mfsa2012-38.html http://www.mozilla.org/security/announce/2012/mfsa2012-40.html http://www.mandriva.com/en/support/security/advisories/?dis=2010.1&name=MDVSA-2012:088-1 ======================== Source RPMs: nspr-4.9.1-1.mga2.src.rpm nss-3.13.5-1.mga2.src.rpm firefox-10.0.5-1.mga2.src.rpm firefox-l10n-10.0.5-1.1.mga2.src.rpm
Advisory looks good. The other packages can be removed from testing for now. Thanks Claire.
Validating then, thankyou everybody \o/ See comment 57 for advisory and srpm's Could sysadmin please push from core/updates_testing to core/updates Also could you please remove these two srpm's from core/updates_testing xulrunner-10.0.5-1.1.mga2.src.rpm gnome-python-extras-2.25.3-38.1.mga2.src.rpm Thanks!
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugsHardware: i586 => AllWhiteboard: mga2-64-OK => mga2-64-OK mga2-32-OK
xulrunner and gnome-python-extras removed. update pushed: https://wiki.mageia.org/en/Support/Advisories/MGASA-2012-0135
Status: NEW => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED