Mozilla Firefox 0.9.3 released, fixing several security vulnerabilities. Bug 253121 - lock icon and certificates spoofable with onunload document.write Bug 249004 - Importing false CA certificate leading to error -8182 (perm DoS), especially exploitable by email Bug 251381 - new libpng buffer overflow vulnerabilities Bug 250906 - null (%00) in filename fakes extension (ftp, file) Reproducible: Always Steps to Reproduce:
Mozilla team : please bump to 1.7.2 and 0.9.3.
Ok, I'm working on this
thunderbird is finished. mozilla and firefox are still in the works. In the case of mozilla enough things have changed that it wasn't a simple bump (at least one patch of ours no longer applies). In the case of firefox it doesn't even build out of the box; they apparently left some files out of the distribution. Stay tuned...
thunderbird is finished. mozilla and firefox are still in the works. In the case of mozilla enough things have changed that it wasn't a simple bump (at least one patch of ours no longer applies). And thanks to the haste of our friends at mozilla.org, neither moz nor ff builds out of the box! :-( Stay tuned...
I simply copied the 0.9.1 ebuild to 0.9.3, and it compiled fine on x86.
I simply copied the 0.9.1 ebuild to 0.9.3, and firefox compiled fine on x86.
mozilla-1.7.2 source package is incomplete http://bugzilla.mozilla.org/show_bug.cgi?id=254346
Thanks Chaze, I'll try that now. My updated ebuild had some modifications, but nothing that I thought would cause the build to fail. It might depend on USE flags. Stay tuned...
*** Bug 59439 has been marked as a duplicate of this bug. ***
*** Bug 59437 has been marked as a duplicate of this bug. ***
mozilla-firefox-0.9.3 mozilla-firefox-bin-0.9.3 mozilla-thunderbird-0.7.3 mozilla-thunderbird-bin-0.7.3 mozilla-bin-1.7.2 These are all in portage now, marked ~arch for the moment. It's still impossible to build mozilla-1.7.2 from source so we're waiting on upstream for that.
*** Bug 57380 has been marked as a duplicate of this bug. ***
*** Bug 59420 has been marked as a duplicate of this bug. ***
agriffis: From CVSweb it looks like you bumped mozilla-firefox-0.9.3 directly with the 0.9.1 keywords, i.e. stable on most arches... I don't think it was your intention ?
Here are the target keywords : mozilla-firefox-0.9.3 : "x86 ppc sparc alpha amd64 ia64" mozilla-firefox-bin-0.9.3 : "x86 amd64" mozilla-thunderbird-0.7.3 : "x86 ~ppc sparc ~alpha amd64 ia64" mozilla-thunderbird-bin-0.7.3 : "~x86" (done) mozilla-bin-1.7.2 : (none, new package) mozilla-1.7.2 (when available) : "x86 ppc sparc alpha amd64 ia64" Please test and mark stable for the moment : x86 : mozilla-firefox-bin-0.9.3 mozilla-thunderbird-0.7.3 ppc : mozilla-firefox-0.9.3 sparc : mozilla-firefox-0.9.3 mozilla-thunderbird-0.7.3 alpha : mozilla-firefox-0.9.3 amd64 : mozilla-firefox-0.9.3 mozilla-firefox-bin-0.9.3 mozilla-thunderbird-0.7.3 ia64 : mozilla-firefox-0.9.3 mozilla-thunderbird-0.7.3
firefox-bin stable on x86.. two more comments on that ebuild: virtual/x11 is twice in RDEPEND and virtual/libc is in DEPEND but is missing from RDEPEND...
mozilla-thunderbird-0.7.3 fails with: gmake[2]: Entering directory `/var/tmp/portage/mozilla-thunderbird-0.7.3/work/mozilla/other-licenses/libart_lgpl' gmake[2]: *** No rule to make target `export'. Stop. gmake[2]: Leaving directory `/var/tmp/portage/mozilla-thunderbird-0.7.3/work/mozilla/other-licenses/libart_lgpl' gmake[1]: *** [tier_1] Error 2 This happened to anyone else? Revelant USE: "+crypt -debug -gtk2 +java -ldap -moznoxft +mozsvg -xinerama -xprint" /var/tmp/portage/mozilla-thunderbird-0.7.3/work/mozilla/other-licenses/libart-lgpl is empty for me.
mozilla-firefox and mozilla-firefox-bin 0.9.3 now stable on amd64.. Thunderbird can wait till I find out what happened with the error up <a href="http://bugs.gentoo.org/show_bug.cgi?id=59419#c17">here</a>.
mozilla-firefox-0.9.3 sparc stable. mozilla-thunderbird-0.7.3 sparc stable thanks to squash. now waiting for moz 1.7.2.
Same result as Comment #17 on ppc with gcc-3.4.1.
Slarti, the thunderbird problem you mentioned was bug 59521. It's fixed now.
GLSA drafted
Back to upstream status waiting for a fix in the 1.7.2 sources bug : http://bugzilla.mozilla.org/show_bug.cgi?id=254346
Link to security fixes, for reference : http://www.mozilla.org/projects/security/known-vulnerabilities.html
mozilla-thunderbird-0.7.3 now stable on amd64, that's amd64 done for now.
Getting odd errors when clicking on links for files (non-web pages) causes an odd 'Gecko' titled error dialogs: XML Parsing Error: not well-formed Location: chrome://mozapps/content/downloads/unknownContentType.xul Line Number 1, Column 1: (2 blank lines) ^ (the carat is red, and like it should point to some code, but is blank) Sorry if this is in the wrong place.
The 1.7.2 Mozilla sources have been fixed upstream (Bug http://bugzilla.mozilla.org/show_bug.cgi?id=254346 has been closed).
Upstream fixed tarballs for Mozilla 1.7.2 back to stable.
Sorry back to ebuild. Still no mozilla ebuild.
mozilla-1.7.2 is now in portage
Now we have a ebuild for mozilla-1.7.2 to mark stable.
Stable on amd64.
Stable on sparc.
Please note that at least for sparc epiphany-1.2.7 was bumped to stable since 1.2.6 didn't build against mozilla-1.7.2.
Epiphany and other variant packages should be updated to reflect new version to allow proper emerges of those packages (they currently break).
stable on ppc
Stable on alpha.
I am getting nsIJVMManager.h: No such file or directory now trying to build galeon. Is that another file missing from Mozilla?
Hmm. My bad. Somehow I don't have USE="java". Either I lost it or now the oji stuff isn't loaded if you don't have it.
ppc x86 please mark mozilla-1.7.2 stable asap.
Stable on x86.
It appears Epiphany and Galeon (and any other gecko-based browsers?) may also be vulnerable to some of these issues (see http://www.slackware.com/security/viewer.php?l=slackware-security&y=2004&m=slackware-security.667659, https://rhn.redhat.com/errata/RHSA-2004-421.html). Mozilla herd: can you confirm that this bug affects these packages? If so, can you fix the RDEPEND so that they build against the new patched versions of Mozilla?
You're right, galeon and epiphany would be affected. However the mozilla team doesn't touch those packages. The gnome team should update the depends.
we'll fix epiphany-1.2.7 to dep hard on moz-1.7.2, needs a bump because it's already stable on an arch. I'll let you know in a second when epiphany-1.2.7-r1 gets added. Galeon is maintained by hanno, CC-ing
epiphany-1.2.7-r1 added & stable on x86 + sparc hanno on CC for fixing galeon
epiphany stable on ppc. please add ppc again when galeon needs testing.
GLSA 200408-22 hanno please fix galeon
I recommend we strip the relevant bullet point from the GLSA, but do not reissue. ---------- Subject: [Full-Disclosure] RE: [ GLSA 200408-22 ] Mozilla, Firefox, Thunderbird: New releases fix vulnerabilities Date: Tuesday 24 August 2004 11:04 From: Gervase Markham <gerv@gerv.net> To: klieber@gentoo.org Cc: bugtraq@securityfocus.com;, full-disclosure@lists.netsys.com;, security-alerts@linuxsecurity.com As has been pointed out to the author of the relevant "advisory" several times, Mozilla has neither a "local zone" nor "predictable cache file locations". The author assumed that the random string generated for his cache file location was the same as everyone else's. I wonder how Gentoo can have fixed, QAed and tested the fix for a vulnerability which doesn't exist? (Note: none of the referenced CVE numbers in the advisory refer to this "issue".) Gerv
ooh. I forgot to mention that when I went back and looked, I couldn't find any reference to the file cache vulnerabilities referenced in the GLSA, either on Mozilla's website or in any of the CVEs. So I think it's fairly safe to assume he's right and the vulnerability doesn't exist.
GLSA updated and not reissued.
galeon-1.3.17 added and depends on >=mozilla-1.7.2-r1
Removing amd64@g.o from cc
Galeon stable on alpha.
Arches please mark Galeon 1.3.17 stable.
sparc was done but not removed, removing...
amd64: please mark galeon-1.3.17 stable
galeon-1.3.17 marked stable on amd64.
Ready for a Galeon/Epiphany GLSA... Or an update of the other one
Thx everybody. GLSA 200408-22 updated and reissued
GLSA 200408-22 contains format bug: <package name="net-www/epiphany" auto="yes" arch="*"> <unaffected range="ge">1.2.7-r1</unaffected> <vulnerable range="lt"> 1.2.7-r1</vulnerable> </package> Please remove the space before the version-spec in vulnerable tag.
Thanks, fixed in CVS
and closed again
