MFSA 2006-08 "AnyName" entrainment and access control hazard (CVE-2006-0299)
MFSA 2006-07 Read beyond buffer while parsing XML (CVE-2006-0298)
MFSA 2006-06 Integer overflows in E4X, SVG and Canvas (CVE-2006-0297)
MFSA 2006-05 Localstore.rdf XML injection through XULDocument.persist()(CVE-2006-0296)
MFSA 2006-04 Memory corruption via QueryInterface on Location, Navigator objects (CVE-2006-0295)
MFSA 2006-03 Long document title causes startup denial of Service (CVE-2005-4134)
MFSA 2006-02 Changing postion:relative to static corrupts memory (CVE-2006-0294)
These issues are fixed in Firefox 220.127.116.11. Apparently no fixed version for Thunderbird and Mozilla Suite.
Mozilla please provide updated ebuilds.
*** Bug 121378 has been marked as a duplicate of this bug. ***
Everything is in spot I will keep track of bugs over next few days then we will make a call to stable. DO NOT call for stable until you get up with me to make sure we have no major problems that need to be addressed.
Jory are we ready to start stable marking?
Everything is in ready. nss-3.11 and nspr-4.6.1-r1 need to be marked stable at same time with any other deps. If arch has a specific problem let me know as soon as possible so we can A:) try and fix it or B:) backport fixes. X86 and AMD64 do not forget about firefox-bin-18.104.22.168
oops. forgot to cc arch's.
Exactly what ebuilds do we need to mark stable that are not vulnerable? I have to inject all of these into the 2006.0 release snapshot and really need to know exactly what I need.
It's highly likely 22.214.171.124 won't work right for sparc, so start thinking "backport".
Note: There should be a 1.0.8 with the fixorz one day.
as I was just informed of a small issue with nspr/nss please stablize nss-3.11-r1 and nspr-4.6.1-r2. That is last known issue I have of major concern, sorry for the inconvience of anyone working on moving packages to stable already.
Since 1.0.8 is in the pipe, it's probably better to wait for it rather than rush stable-ization of the 1.5 branch. There are only two big things in this update. One that only affects the 1.5-line (which was never stable so we can consider it fixed) and the other which has embargoed details until 1.0.8 is out... So no real hurry here.
If everyone agrees I will set this back to [upstream] status.
So, we are waiting for 1.0.8 then?
It all depends on the ETA, but I prefer that stableization of 1.5 is decorrelated of security forced upgrade... Removing arches for now.
Any update about a time frame with 1.0.8?
It should not appear before mid-March... If there is global consensus amongst arches that the 1.5 branch is stable, feel free to stableize it. In which case we'll release a GLSA when all security-supported arches will have done that stableization.
Mozilla team, arch teams: please reply to comment #15
I have not found any reason to prevent 126.96.36.199 from going stable. If someone has any question email me and I will answer them the best I can.
It's still broken for sparc, and AFAIK for alpha too.
I know that there's a lot of dislike about the 1.5 tree by quite a few users. Now this isn't to say that we shouldn't go stable with a 1.5. However, I feel its important to take it into consideration. I will however follow what other arches feel is appropriate. As we've waited for a month now..I don't think the two or so weeks for 1.0.8 is going to make much difference at this point either.
x86 shouldn't have any problems with 1.5 if it is decided to go that route instead of waiting for 1.0.8.
I've done (and still doing while writing this) some testing with www-client/mozilla-firefox-188.8.131.52-r2 with "-debug +gnome +ipv6 +java -mozdevelop -xinerama -xprint" against x86. To do that, i've also unmasked
dev-libs/nss-3.11-r1. As far as i can tell, everything seems to work fine for me. I've also verified that net-www/mplayerplug-in-2.8.0 still does it's job without a remerge. If anyone is interested, i can also test 184.108.40.206-r3, or verify my results on another x86 system.
Portage 2.0.54 (default-linux/x86/2006.0, gcc-3.4.5, glibc-2.3.5-r2, 2.6.15-gentoo-r5 i686)
System uname: 2.6.15-gentoo-r5 i686 AMD Athlon(tm) XP 2400+
Gentoo Base System version 1.6.14
dev-lang/python: 2.3.5-r2, 2.4.2
sys-devel/autoconf: 2.13, 2.59-r7
sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
CFLAGS="-O2 -march=athlon-xp -pipe"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=athlon-xp -pipe"
FEATURES="autoconfig colission-protect distlocks sandbox sfperms strict"
USE="x86 3dnow 3dnowext X a52 aalib alsa apm audiofile avi berkdb bitmap-fonts bonobo bzip2 bzlib cairo cdr cli crypt css ctype cups curl dba dbus divx4linux dri dts dv dvd dvdr dvdread emboss encode evo exif expat fam fame fastbuild ffmpeg firefox flac foomaticdb force-cgi-redirect fortran ftp gd gdbm gif glut gmp gnome gphoto2 gpm gstreamer gtk gtk2 gtkhtml guile hal idn imagemagick imlib ipv6 java jpeg junit lcms libg++ libwww mad memlimit mhash mikmod mmx mmxext mng motif mp3 mpeg nautilus ncurses nls nptl nsplugin nvidia ogg oggvorbis openal opengl pam pcre pdflib perl plotutils png posix python quicktime readline real ruby sdl session simplexml slang soap sockets speex spell spl sqlite sse ssl subtitles svga tcltk tcpd tetex theora tiff tokenizer truetype truetype-fonts type1-fonts udev unicode usb vcd vorbis win32codecs wma xine xml xml2 xmms xsl xv xvid zlib linguas_en linguas_de userland_GNU kernel_linux elibc_glibc"
Unset: ASFLAGS, CTARGET, LDFLAGS
Well, i've just noticed, shortly after posting my last comment, that there is at least one minor issue with mozilla-firefox-220.127.116.11-r2. It seems to consume lot's of cpu cycles when drawing sites with flash animations. For example, try
www.derstandard.at. I've only noticed this, because firefox suddenly was a bit slow when scrolling .... With an athlon-xp 2400+, 768MB ram and a GeForce3 Ti 200, that is not what you expect.
well, the flash-animation slowing down firefox-1.5.01-r2 on www.derstandard.at seemed to have been a specific advertisment that actually played some sort of movie. Now that this advertisment is gone, firefox-1.5.01-r2 no longer consumes lot's of cpu when viewing this site, allthough this stite still contains lot's of flash animations. I've also tested firefox-1.5.01-r2 on http://www.myspace.com/hippe07, a page with must be a nightmare for every browser. This site slows firefox-18.104.22.168-r2 down heavily, but this is also true for 1.0.7.
Recapitulating: I'm now using firefox-22.214.171.124-r2 for almost three days as my default browser, what means that i've used the software a lot, and did not face any real problems. In my opinion this package is ready for stable on x86.
Regrouping issues on the Moz-1.0.8 release bug
*** This bug has been marked as a duplicate of 129924 ***
remove hppa from cc
i add this one to the list of known vulns :
"View Image" Local Resource Linking Weakness
( see also http://secunia.com/advisories/19698/ )