CVE-2009-2462 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-2462): The browser engine in Mozilla Firefox before 3.0.12 and Thunderbird allows remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via vectors related to (1) the frame chain and synchronous events, (2) a SetMayHaveFrame assertion and nsCSSFrameConstructor::CreateFloatingLetterFrame, (3) nsCSSFrameConstructor::ConstructFrame, (4) the child list and initial reflow, (5) GetLastSpecialSibling, (6) nsFrameManager::GetPrimaryFrameFor and MathML, (7) nsFrame::GetBoxAscent, (8) nsCSSFrameConstructor::AdjustParentFrame, (9) nsDOMOfflineResourceList, and (10) nsContentUtils::ComparePosition.
CVE-2009-2463 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-2463): Integer overflow in a base64 decoding function in Mozilla Firefox before 3.0.12 and Thunderbird allows remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via unspecified vectors. CVE-2009-2464 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-2464): The nsXULTemplateQueryProcessorRDF::CheckIsSeparator function in Mozilla Firefox before 3.0.12, SeaMonkey 2.0a1pre, and Thunderbird allows remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via vectors related to loading multiple RDF files in a XUL tree element. CVE-2009-2465 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-2465): Mozilla Firefox before 3.0.12 and Thunderbird allow remote attackers to cause a denial of service (memory corruption and application crash) or execute arbitrary code via vectors involving double frame construction, related to (1) nsHTMLContentSink.cpp, (2) nsXMLContentSink.cpp, and (3) nsPresShell.cpp, and the nsSubDocumentFrame::Reflow function. CVE-2009-2466 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-2466): The JavaScript engine in Mozilla Firefox before 3.0.12 and Thunderbird allows remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via vectors related to (1) nsDOMClassInfo.cpp, (2) JS_HashTableRawLookup, and (3) MirrorWrappedNativeParent and js_LockGCThingRT. CVE-2009-2467 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-2467): Mozilla Firefox before 3.0.12 and 3.5 before 3.5.1 allows remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code via vectors involving a Flash object, a slow script dialog, and the unloading of the Flash plugin, which triggers attempted use of a deleted object. CVE-2009-2469 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-2469): Mozilla Firefox before 3.0.12 does not properly handle an SVG element that has a property with a watch function and an __defineSetter__ function, which allows remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via a crafted document, related to a certain pointer misinterpretation. CVE-2009-2470 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-2470): Mozilla Firefox before 3.0.12, and 3.5.x before 3.5.2, allows remote SOCKS5 proxy servers to cause a denial of service (data stream corruption) via a long domain name in a reply. CVE-2009-2471 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-2471): The setTimeout function in Mozilla Firefox before 3.0.12 does not properly preserve object wrapping, which allows remote attackers to execute arbitrary JavaScript with chrome privileges via a crafted call, related to XPCNativeWrapper. CVE-2009-2472 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-2472): Mozilla Firefox before 3.0.12 does not always use XPCCrossOriginWrapper when required during object construction, which allows remote attackers to bypass the Same Origin Policy and conduct cross-site scripting (XSS) attacks via a crafted document, related to a "cross origin wrapper bypass."
CVE-2009-2662 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-2662): The browser engine in Mozilla Firefox before 3.0.13, and 3.5.x before 3.5.2, allows remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via vectors related to the TraceRecorder::snapshot function in js/src/jstracer.cpp, and unspecified other vectors. CVE-2009-2663 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-2663): libvorbis before r16182, as used in Mozilla Firefox before 3.0.13 and 3.5.x before 3.5.2 and other products, allows context-dependent attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via a crafted .ogg file. CVE-2009-2664 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-2664): The js_watch_set function in js/src/jsdbgapi.cpp in the JavaScript engine in Mozilla Firefox before 3.0.13, and 3.5.x before 3.5.2, allows remote attackers to cause a denial of service (assertion failure and application exit) or possibly execute arbitrary code via a crafted .js file, related to a "memory safety bug."
Please bump Firefox. Updated Seamonkey and Thunderbird are not yet available.
*** Bug 280234 has been marked as a duplicate of this bug. ***
CVE-2009-2663 is a bug in libvorbis and is handled in #280590.
Arches, please test and mark stable: =www-client/mozilla-firefox-3.5.2 Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 sparc x86"
Arches: please don't stable yet, I was too fast here, sorry for the fail/spam. Mozilla: Is it ok to go stable yet?
Craig and Tobias, instead of adding new bugs and CVEs to existing bugs, can you please try to sort out which new vulnerabilities: (1) affect stable Firefox (3.0), thus warrant to be on an A* bug. (2) affect unstable Firefox (3.5) only, thus should be filed on a separate bug, e.g. 280234. With that in mind, please determine which release fixes which vulnerabilities. If a (2) vulnerability is fixed in, e.g. the 3.5.2 release, the ~arch bug can be closed. If a (1) bug is fixed in, e.g. 3.0.13, we can stable that version. If a (1) bug is fixed in a new major version only, it may require stabling of that version. At any rate, please do not just "collect" unrelated vulnerabilities in one bug, as it makes handling so much harder, leads to mistakes as the two comments above show, and the research needs to be done sometime anyway.
net-libs/xulrunner-1.9.0.13, www-client/mozilla-firefox[-bin]-3.0.13 are in the tree. There is no thunderbird nor seamonkey release date. So let's go ahead meanwhile. net-libs/xulrunner-1.9.0.10: Arches: alpha arm amd64 hppa ia64 ppc ppc64 sparc x86 www-client/mozilla-firefox-3.0.10: Arches: alpha arm amd64 hppa ia64 ppc ppc64 sparc x86 www-client/mozilla-firefox-bin-3.0.10: Arches: amd64 x86
Thats what happens when you copy it :P These are the correct versions: ------------------------------------ net-libs/xulrunner-1.9.0.13, www-client/mozilla-firefox[-bin]-3.0.13 are in the tree. There is no thunderbird nor seamonkey release date. So let's go ahead meanwhile. net-libs/xulrunner-1.9.0.13: Arches: alpha arm amd64 hppa ia64 ppc ppc64 sparc x86 www-client/mozilla-firefox-3.0.13: Arches: alpha arm amd64 hppa ia64 ppc ppc64 sparc x86 www-client/mozilla-firefox-bin-3.0.13: Arches: amd64 x86
With this bug, can you please eiter mask and last-rite xulrunner-bin or build a new version that contains the fix? The version we have in stable has not been updated in 8 months.
Both stable for HPPA.
Created attachment 201550 [details] failure log of patch application With USE=-* * 097_noxul_glibc-maxpathlen.patch ... * Failed Patch: 097_noxul_glibc-maxpathlen.patch ! * ( /var/tmp/portage/www-client/mozilla-firefox-3.0.13/work/patch/097_noxul_glibc-maxpathlen.patch )
net-libs/xulrunner-1.9.0.13 is failing on ppc (see attached log) USE="dbus startup-notification -custom-optimization -gnome -java" Build log is available here: http://dev.gentoo.org/~volkmar/xulrunner-1.9.0.13-build.log emerge --info: Portage 2.2_rc38 (default/linux/powerpc/ppc32/2008.0/desktop, gcc-4.3.2, glibc-2.9_p20081201-r2, 2.6.27-gentoo-r8 ppc) ================================================================= System uname: Linux-2.6.27-gentoo-r8-ppc-7447A,_altivec_supported-with-glibc2.0 Timestamp of tree: Tue, 18 Aug 2009 00:45:01 +0000 app-shells/bash: 3.2_p39 dev-lang/python: 2.5.4-r3 dev-util/cmake: 2.6.2-r1 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.13, 2.63-r1 sys-devel/automake: 1.5, 1.6.3, 1.7.9-r1, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.4 virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="ppc" CBUILD="powerpc-unknown-linux-gnu" CFLAGS="-O2 -pipe -mcpu=7450 -mtune=7450 -maltivec -mabi=altivec -fno-strict-aliasing -frename-registers -fivopts -ftree-vectorize" CHOST="powerpc-unknown-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -pipe -mcpu=7450 -mtune=7450 -maltivec -mabi=altivec -fno-strict-aliasing -frename-registers -fivopts -ftree-vectorize" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests distlocks fixpackages parallel-fetch preserve-libs protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://mirror.ovh.net/gentoo-distfiles/ http://mirror.muntinternet.net/pub/gentoo/" LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="en en_US" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/usr/portage/tmp" PORTDIR="/usr/portage/tree" PORTDIR_OVERLAY="/usr/local/portage/layman/sunrise /usr/local/portage/layman/x11 /usr/local/portage/layman/gnome /home/volkmar/projects/gentoo/voip /usr/local/portage/oldworld" SYNC="rsync://oldworld.fr/gentoo-portage" USE="X a52 aac acl alsa altivec avahi berkdb bluetooth branding bzip2 cairo cddb cdr cjk cli cracklib crypt curl dbus dri dvd emboss encode evo fam firefox flac fontconfig fortran gdbm gif gnutls gstreamer gtk hal iconv imagemagick imlib isdnlog jpeg latex ldap libnotify mad matroska mikmod mp3 mp4 mpeg mudflap musepack ncurses nls nocd nodrm nptl nptlonly ogg openal opengl openmp pam pcre pdf perl png ppc ppds pppd python qt3support readline reflection ruby sdl session speex spell spl ssl startup-notification svg symlink sysfs tcpd tetex theora tiff truetype unicode usb userlocales videos vim-syntax vorbis wifi x264 xcomposite xml xorg xscreensaver xulrunner xv xvid zlib" ALSA_CARDS="aoa aoa-fabric-layout aoa-onyx aoa-soundbus aoa-soundbus-i2s aoa-tas aoa-toonie powermac usb-audio via82xx" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev mouse keyboard synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en en_US" USERLAND="GNU" VIDEO_CARDS="nv nouveau" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
(In reply to comment #10) > Thats what happens when you copy it :P These are the correct versions: > > ------------------------------------ > > net-libs/xulrunner-1.9.0.13, www-client/mozilla-firefox[-bin]-3.0.13 are in the > tree. There is no thunderbird nor seamonkey release date. > > So let's go ahead meanwhile. > I will get an updated ebuild in the tree later today. > net-libs/xulrunner-1.9.0.13: > Arches: alpha arm amd64 hppa ia64 ppc ppc64 sparc x86 > > www-client/mozilla-firefox-3.0.13: > Arches: alpha arm amd64 hppa ia64 ppc ppc64 sparc x86 > www-client/mozilla-firefox-bin-3.0.13: > Arches: amd64 x86 > All archs please stabilize 3.5.2-r1 and associated deps. Any problems let me know and I will resolve them as quick as possible. www-client/mozilla-firefox-3.5.2-r1: Archs: alpha amd64 arm hppa ia64 ppc ppc64 sparc x86 net-libs/xulrunner-1.9.1.2-r1: Archs: alpha amd64 arm hppa ia64 ppc ppc64 sparc x86 www-client/mozilla-firefox-bin-3.5.2: Arches: amd64 x86 If anyone has any questions please ping me on irc or via email. The reason behind 3.5.x going stable as many bug fixes are included that will not be backported upstream that are needed by other parts of gentoo, like hardened support.(In reply to comment #11) > With this bug, can you please eiter mask and last-rite xulrunner-bin or build a > new version that contains the fix? The version we have in stable has not been > updated in 8 months. >
I've stabilized for ppc: =x11-libs/cairo-1.8.8 =dev-libs/nspr-4.8 (bug 280837) =dev-libs/nss-3.12.3-r1 (bug 280839) =net-libs/xulrunner-1.9.1.2-r1 =www-client/mozilla-firefox-3.5.2-r1 Even if I've stabilized the ebuild, I would like to report this: * Fallback PaX marking -m * /usr/portage/tmp/portage/www-client/mozilla-firefox-3.5.2-r1/image///usr/lib/mozilla-firefox/firefox TYPE PAX FILE ET_EXEC --mxe- /usr/portage/tmp/portage/www-client/mozilla-firefox-3.5.2-r1/image///usr/lib/mozilla-firefox/firefox >>> Completed installing mozilla-firefox-3.5.2-r1 into /usr/portage/tmp/portage/www-client/mozilla-firefox-3.5.2-r1/image/ * QA Notice: Pre-stripped files found: * /usr/lib/mozilla-firefox/firefox strip: powerpc-unknown-linux-gnu-strip --strip-unneeded -R .comment usr/lib/mozilla-firefox/components/libbrowserdirprovider.so usr/lib/mozilla-firefox/components/libbrowsercomps.so That's a minor QA issue (pre-stripped) which is, I suppose, linked to the message just before.
(In reply to comment #16) [snip] > * QA Notice: Pre-stripped files found: > * /usr/lib/mozilla-firefox/firefox > strip: powerpc-unknown-linux-gnu-strip --strip-unneeded -R .comment > usr/lib/mozilla-firefox/components/libbrowserdirprovider.so > usr/lib/mozilla-firefox/components/libbrowsercomps.so > > That's a minor QA issue (pre-stripped) which is, I suppose, linked to the > message just before. > Sorry for spamming everyone. Just to say bug 238947 is about the pre-stripped issue.
x86 stable
(In reply to comment #15) > If anyone has any questions please ping me on irc or via email. The reason > behind 3.5.x going stable as many bug fixes are included that will not be > backported upstream that are needed by other parts of gentoo, like hardened > support. This seems a bit quick to me for just that. You haven't checked the reverse deps and this breaks the stable tree.
(In reply to comment #19) > (In reply to comment #15) > > If anyone has any questions please ping me on irc or via email. The reason > > behind 3.5.x going stable as many bug fixes are included that will not be > > backported upstream that are needed by other parts of gentoo, like hardened > > support. > > This seems a bit quick to me for just that. You haven't checked the reverse > deps and this breaks the stable tree. > If we stop everytime something breaks against xulrunner/firefox we would never move anything forward. Firefox-3.5 and xulrunner-1.9.1 have been around long enough they belong stable, I am working on xulrunner-1.9.2 and firefox-3.6 already which will be in testing within the next few weeks.
Stable for HPPA.
(In reply to comment #20) > If we stop everytime something breaks against xulrunner/firefox we would never > move anything forward. Firefox-3.5 and xulrunner-1.9.1 have been around long > enough they belong stable, Being a stable software does not mean it should belong in Gentoo stable. It has to be friends with all the other ebuilds that are already there ;-) That said, ... (In reply to comment #19) > This seems a bit quick to me for just that. You haven't checked the reverse > deps and this breaks the stable tree. ... what exactly is broken in the tree by xulrunner 1.9.1? Please open bugs and mark them as blockers of this bug.
(In reply to comment #20) > If we stop everytime something breaks against xulrunner/firefox we would never > move anything forward. This is only and arguably acceptable for ~arch. Now that problems have been identified and hopefuly fixed in ~arch I consider it a shame that it is not taken into consideration when stabilising it. (In reply to comment #22) > ... what exactly is broken in the tree by xulrunner 1.9.1? > Please open bugs and mark them as blockers of this bug. Something like grepping the tree for =net-libs/xulrunner-1.9.0* deps tells me: app-office/openoffice dev-java/swt dev-util/devhelp www-client/epiphany
I'm removing arches for now. Breaking that amount of stable reverse dependencies is unacceptable and needs to be fixed.
Jory, I see you have been aware of the stable breakage from comments in other bug reports (e.g., gnome stabling). Please mark those bug reports as blockers of this bug as Firefox stabling has caused an issue in the stable tree that the other bug can solve. Epiphany 2.24* cannot be fixed easily, see bug 265700. We have hppa, ppc and x86 already stable. I think they should be reverted before users see the horrible mess that is upgrade-downgrade cycles. Arches, please comment.
(In reply to comment #25) > Arches, please comment. I reverted all stable keywords.
Why is firefox-3.5.x stabilization handled as a security issue? Firefox-3.0 branch is still security supported to my knowledge and it would be nicer if 3.5 stabilization wouldn't be hurried like that in the name of security when 3.0 is security supported as well. We can't guarantee a good enough response time (for security concerns) on epiphany-2.26 stabilization due to whole GNOME-2.26 being involved and quite some show stoppers on the whole of it to be resolved first together with non-gnome maintainers. And we shouldn't have to hurry - 3.0 is ought to be security supported.
We don't need gnome-2.26 stable, just epiphany-2.26 (which should work fine w/o the entire gnome-2.26)
(In reply to comment #27) > Why is firefox-3.5.x stabilization handled as a security issue? Firefox-3.0 > branch is still security supported to my knowledge and it would be nicer if 3.5 > stabilization wouldn't be hurried like that in the name of security when 3.0 is > security supported as well. For the facts: "Firefox 3.0.x will be maintained with security and stability updates until January 2010. All users are strongly encouraged to upgrade to Firefox 3.5." (from the Mozilla website)
I have opened bug 282179 for security stabling of Firefox 3.0.13 and the other non-major bumps. This should be the fast and secure way to go for Gentoo stable users. At the same time we can work together and prepare the stable tree for Firefox 3.5, and stable that without unnecessary lag. Security team, we need to assess which vulnerability fixes are missing in 3.0 updates.
=mail-client/mozilla-thunderbird[-bin]-2.0.0.23 in the tree
We're going to try and get 3.5.2 into the 10.0 release...
=www-clients/seamonkey[bin]-1.1.18 are in the tree security team handle when you all want to bring archs in for stable. :)
(In reply to comment #33) > =www-clients/seamonkey[bin]-1.1.18 are in the tree security team handle when > you all want to bring archs in for stable. :) Thanks, the stabling is handled in bug 286721.
amd64 stable
Could you please enlighten me, what exactly needs to be stabilised for this bug and bug 280234?
(In reply to comment #36) > Could you please enlighten me, what exactly needs to be stabilised for this bug > and bug 280234? > As for amd64, I've got away by simply doing the bugs in "depends" and "blocks" list at the same time, that's mozilla-firefox, mozilla-firefox-bin, xulrunner, and galeon. Nothing special here, I don't get why this is being dragged behind...
Current status: we need firefox-3.5.3 is in-tree, and we need that stable (more security fixes). Target keywords: www-client/mozilla-firefox-3.5.3-r1: alpha arm hppa ia64 ppc ppc64 x86 net-libs/xulrunner-1.9.1.3-r1: alpha arm hppa ia64 ppc ppc64 x86 dev-libs/nspr-4.8: ppc64 www-client/galeon-2.0.7-r1: x86 www-plugins/noscript-1.9.6.6: ppc64 www-client/epiphany-2.26.3-r2: alpha amd64 arm hppa ia64 ppc ppc64 x86 media-video/vlc-1.0.2: ppc dev-java/swt-3.4-r4: ppc media-sound/rhythmbox-0.12.5: amd64 ppc ppc64 x86 Some of these are in bugs blocking this bug; please remove yourself from CC for those bugs as well. Newer revision of epiphany is useful for users due to a favicon fix; so it's getting a free ride (easy stable for arches that already have -r1 stable) Newer rhythmbox is needed to prevent compile failures with USE=nsplugin @ppc: You will probably be unable to do firefox/xulrunner till bug 282390 is resolved. Please do just epiphany, swt, and rhythmbox.
Addition: media-sound/rhythmbox-0.12.5: bug 286074 (for udev and friends). If that's the only thing blocking stabilization of firefox for you, please go ahead and tackle that later (amd64 did that), it's a minor issue.
3.5.4 and 3.0.15 are out with additional fixes.
(In reply to comment #40) > 3.5.4 and 3.0.15 are out with additional fixes. > xulrunner-1.9.1.4/firefox-3.5.4 already in tree, a new bug should be opened to track new security issues.
(In reply to comment #41) > (In reply to comment #40) > > 3.5.4 and 3.0.15 are out with additional fixes. > > > xulrunner-1.9.1.4/firefox-3.5.4 already in tree, a new bug should be opened to > track new security issues. > Nevertheless, no point in stabilizing a vulnerable version of Firefox. @arches: please do xulrunner-1.9.1.4/firefox-3.5.4 instead
(In reply to comment #42) > @arches: please do xulrunner-1.9.1.4/firefox-3.5.4 instead > No. Do your stabilization on bug 290892.
.9.1.4.ebuild new revision: 1.4; previous revision: 1.3 0 bash jeroen@astrid /keeps/gentoo/cvs/gentoo-x86/www-client/mozilla-firefox $ myresources jeroen@astrid /keeps/gentoo/cvs/gentoo-x86/www-client/mozilla-firefox $ stablehppa mozilla-firefox-3.5.4.ebuild 290892 mozilla-firefox-3.5.4.ebuild -KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~ppc ~ppc64 -sparc ~x86" +KEYWORDS="~alpha ~amd64 ~arm hppa ~ia64 ~ppc ~ppc64 -sparc ~x86" Keywords in /keeps/gentoo/cvs/gentoo-x86 for www-client/mozilla-firefox : | a a a a h i m m p p s s s s x x | l m m r p a 6 i p p 3 h p p 8 8 | p d d m p 6 8 p c c 9 a a 6 6 | h 6 6 a 4 k s 6 0 r r - | a 4 4 4 c c f | - - b | f f s | b b d | s s | d d ---------+-------------------------------- 2.0.0.19 | + + + + + ~ + + + + ~ 3.0.11 | + + + + + + + + + 3.0.13 | + + + + + + + + + 3.0.14 | + + + + + + + + + 3.5.3 | ~ ~ ~ ~ ~ ~ ~ - ~ 3.5.3-r1 | ~ + ~ ~ ~ ~ ~ - ~ 3.5.4 | ~ ~ ~ + ~ ~ ~ - ~ * Committing with: "Stable for HPPA (bug #290892)." RepoMan scours the neighborhood... RDEPEND.bad 1 www-client/mozilla-firefox/mozilla-firefox-3.5.4.ebuild: hppa(default/linux/hppa/10. 0) ['~net-libs/xulrunner-1.9.1.3[sqlite,-sqlite,-java]'] DEPEND.bad 1 www-client/mozilla-firefox/mozilla-firefox-3.5.4.ebuild: hppa(default/linux/hppa/10. 0) ['~net-libs/xulrunner-1.9.1.3[sqlite,-sqlite,-java]'] KEYWORDS.dropped 6 www-client/mozilla-firefox/mozilla-firefox-3.0.11.ebuild: mips x86-fbsd www-client/mozilla-firefox/mozilla-firefox-3.0.13.ebuild: mips x86-fbsd www-client/mozilla-firefox/mozilla-firefox-3.0.14.ebuild: mips x86-fbsd www-client/mozilla-firefox/mozilla-firefox-3.5.3.ebuild: mips sparc x86-fbsd www-client/mozilla-firefox/mozilla-firefox-3.5.3-r1.ebuild: mips sparc x86-fbsd www-client/mozilla-firefox/mozilla-firefox-3.5.4.ebuild: mips sparc x86-fbsd Note: use --include-dev (-d) to check dependencies for 'dev' profiles Please fix these important QA issues first. RepoMan sez: "Make your QA payment on time and you'll never see the likes of me."
nyhm seems to have fixed that. Stable for HPPA.
*** Bug 291615 has been marked as a duplicate of this bug. ***
Next firefox bump. Should we just proceed?
(In reply to comment #47) > Next firefox bump. Should we just proceed? > They seem to be in overdrive mode :) +1 from me to just stabilize 3.5.5 instead (no security fixes, just crasher fixes)
+1 We shouldn't stable a firefox version which mozilla declared as unstable if we can stable the fixed version instead.
(In reply to comment #48) > (In reply to comment #47) > > Next firefox bump. Should we just proceed? > +1 from me to just stabilize 3.5.5 instead (no security fixes, just crasher > fixes) Alright, some of the "crasher fixes" in 3.5.5 seem to cause other problems; bug 280114 & bug 292256 . Hence, arches should do 3.5.4 instead.
Please keyword www-client/icecat-3.5.4 stable at same time. This is required as iceweasel useflag will throw an error warnng user to remove mozilla-firefox and install icecat.
ppc/ppc64 are done.
icecat done on x86
What is covered by this bug over bug 297532 ? The only doubt I have is about mozilla-firefox-bin, since we have 3.5.3 stable (that would "fix" this bug), but maybe a 3.5.6 would be added soon. Anyway, it could be handled on a new bug :-/ Only taking care about the summary, seems that amd64 already have newer versions stable, then, we could be removed from CC list, but maybe I am missing something Thanks
I don't think we're needed here anymore...
Nothing for mozilla team to do here, none of the affected versions/packages are in-tree anymore.
This issue was resolved and addressed in GLSA 201301-01 at http://security.gentoo.org/glsa/glsa-201301-01.xml by GLSA coordinator Sean Amoss (ackle).