Bug 6548 - firefox needs to be updated to 10.0.5 for security issues
: firefox needs to be updated to 10.0.5 for security issues
Status: RESOLVED FIXED
Product: Mageia
Classification: Unclassified
Component: Security
: 2
: All Linux
: Normal Severity: normal
: ---
Assigned To: QA Team
:
:
: mga2-64-OK mga2-32-OK
: validated_update
:
: 6389
  Show dependency treegraph
 
Reported: 2012-06-23 17:26 CEST by David Walser
Modified: 2012-06-28 22:34 CEST (History)
8 users (show)

See Also:
Source RPM: firefox-10.0.4-1.mga2.src.rpm
CVE:


Attachments

Description David Walser 2012-06-23 17:26:14 CEST
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.
Comment 1 David Walser 2012-06-23 17:49:15 CEST
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
Comment 2 David Walser 2012-06-23 18:15:25 CEST
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
Comment 3 user7 2012-06-24 16:42:19 CEST
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...
Comment 4 user7 2012-06-25 02:15:21 CEST
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
Comment 5 claire robinson 2012-06-25 15:41:12 CEST
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.
Comment 6 claire robinson 2012-06-25 15:58:15 CEST
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
Comment 7 claire robinson 2012-06-25 16:03:15 CEST
Have the lists here changed David or do others still need to be rebuilt?

https://wiki.mageia.org/en/Updates/Firefox
Comment 8 David Walser 2012-06-25 16:17:10 CEST
(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.
Comment 9 D Morgan 2012-06-25 16:35:50 CEST
then update it please.
Comment 10 David Walser 2012-06-25 16:36:22 CEST
(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.
Comment 11 David Walser 2012-06-25 16:37:38 CEST
(In reply to comment #9)
> then update it please.

I'd rather just delete it, but I don't think Wikis allow that.
Comment 12 D Morgan 2012-06-25 16:38:55 CEST
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
Comment 13 David Walser 2012-06-25 16:49:32 CEST
(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.
Comment 14 Sander Lepik 2012-06-25 17:04:00 CEST
(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?
Comment 15 claire robinson 2012-06-25 17:07:26 CEST
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.
Comment 16 David Walser 2012-06-25 17:16:48 CEST
(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.
Comment 17 David Walser 2012-06-25 17:17:46 CEST
(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?
Comment 18 Sander Lepik 2012-06-25 17:22:06 CEST
(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.
Comment 19 David Walser 2012-06-25 17:25:54 CEST
(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.
Comment 20 Sander Lepik 2012-06-25 17:28:55 CEST
(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 :)
Comment 21 David Walser 2012-06-25 17:29:49 CEST
(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
Comment 22 claire robinson 2012-06-25 17:33:31 CEST
I used the tutorial for swt built in to eclipse. It opened a window titled Hello World.
Comment 23 claire robinson 2012-06-25 17:35:25 CEST
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?
Comment 24 David Walser 2012-06-25 17:44:31 CEST
(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).
Comment 25 claire robinson 2012-06-25 18:44:15 CEST
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
Comment 26 David GEIGER 2012-06-25 21:11:11 CEST
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
Comment 27 claire robinson 2012-06-26 17:37:27 CEST
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.
Comment 28 claire robinson 2012-06-26 19:02:56 CEST
Testing xulrunner i586. I'm writing a howto for the wiki too.
Comment 29 user7 2012-06-26 22:42:52 CEST
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!
Comment 30 claire robinson 2012-06-27 00:11:10 CEST
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?
Comment 31 David Walser 2012-06-27 00:50:53 CEST
(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.
Comment 32 David Walser 2012-06-27 00:52:29 CEST
(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.
Comment 33 claire robinson 2012-06-27 14:13:45 CEST
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.
Comment 34 D Morgan 2012-06-28 14:34:41 CEST
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
Comment 35 D Morgan 2012-06-28 14:36:25 CEST
i will do the same on mga2 in about an hour
Comment 36 D Morgan 2012-06-28 15:44:07 CEST
package is now available in mga2 too
Comment 37 claire robinson 2012-06-28 16:02:09 CEST
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?
Comment 38 claire robinson 2012-06-28 16:05:30 CEST
Should firefox be separated from the xulrunner/libxulrunner packages maybe?
Comment 39 D Morgan 2012-06-28 16:45:06 CEST
this is already done. Firefox doesn't need xulrunned anymore.
xulrunner is only needed by other apps.
Comment 40 claire robinson 2012-06-28 16:59:46 CEST
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

?
Comment 41 D Morgan 2012-06-28 17:26:44 CEST
seems good. 


what about gnome-python-extras ?
Comment 42 David Walser 2012-06-28 17:41:40 CEST
(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.
Comment 43 claire robinson 2012-06-28 17:42:21 CEST
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?
Comment 44 David Walser 2012-06-28 17:46:19 CEST
(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?
Comment 45 claire robinson 2012-06-28 17:53:20 CEST
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)
Comment 46 claire robinson 2012-06-28 17:54:02 CEST
Yes, it worked David, see comment 25
Comment 47 claire robinson 2012-06-28 17:54:29 CEST
Perhaps eclipse should have it's own bug?
Comment 48 David Walser 2012-06-28 17:57:05 CEST
(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.
Comment 49 claire robinson 2012-06-28 18:03:10 CEST
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.
Comment 50 D Morgan 2012-06-28 18:03:41 CEST
what do you mean ?  in mga1 Firefox doesn't need xulrunner neither
Comment 51 David Walser 2012-06-28 18:12:37 CEST
(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.
Comment 52 claire robinson 2012-06-28 18:29:35 CEST
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?
Comment 53 D Morgan 2012-06-28 18:31:27 CEST
yes please open a bugreport for eclipse but don't block the update for this.
Comment 54 claire robinson 2012-06-28 18:36:40 CEST
David would you handle the eclipse update please.

I'll create a BR for xulrunner and then validate this one
Comment 55 claire robinson 2012-06-28 18:59:09 CEST
Bug 6610 created for xulrunner
Comment 56 David Walser 2012-06-28 19:03:00 CEST
(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?
Comment 57 claire robinson 2012-06-28 19:11:29 CEST
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
Comment 58 David Walser 2012-06-28 19:22:16 CEST
Advisory looks good.  The other packages can be removed from testing for now.

Thanks Claire.
Comment 59 claire robinson 2012-06-28 19:29:06 CEST
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!
Comment 60 Thomas Backlund 2012-06-28 22:34:56 CEST
xulrunner and gnome-python-extras removed.

update pushed:
https://wiki.mageia.org/en/Support/Advisories/MGASA-2012-0135

Note You need to log in before you can comment on or make changes to this bug.