The X.Org Foundation is pleased to announce X11R6.8.1, the latest stable release of X.Org, the X standard implementation. This version is purely a security release, addressing multiple integer and stack overflows in libXpm, the X Pixmap library; all known versions of X (both XFree86 and X.Org) are affected, so all users of X are strongly encouraged to upgrade. Vendors should have patches available for their versions of X. The CVE numbers for these vulnerabilities are CAN-2004-0687 (integer overflows) and CAN-2004-0688 (stack overflows). For the 6.8.1 release, two choices have been provided -- the standard set of seven tarballs, and a single tarball. If you download the traditional split tarballs, the first three contain everything except the fonts and general X11 documentation. Those three are sufficient for building X11R6.8 if you already have a set of fonts. The fourth and fifth contain the fonts. The sixth contains the source for the general X11 documentation. The seventh contains the general X11 documentation in hardcopy format. For the single tarball (xorg-6.8.0.tar.gz), everything described in the previous paragraph is available in the single tarball. Downloads are available from: http://freedesktop.org/~xorg/X11R6.8.1/src/ -- Daniel Stone <daniel at freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org
I'm running a test compile of the patched 6.7.0 right now, 6.8.1 coming up soon.
Seems like a little confusion going on w/ the security release. See http://freedesktop.org/pipermail/xorg/2004-September/003196.html -- it announces that a release will be made tomorrow, but the previous posts say there was already one.
I'm holding off till tomorrow to see whether more changes are made.
I suppose old xfree is vulnerable... Do you plan to issue fixed packages for xfree too ? If not, then we'll security-mask xfree, which will probably help getting rid of it. But I don't know if we're ready for this on all arches etc.. You have the cards in hand, you decide and we'll follow.
I suppose that's a good idea, given my previous statement of support til 2005.0. I'll be pulling the heavily modified xfree then (currently -r7) and replacing it with a security-fixed -r6. If anyone needs the current -r7 (possibly hardened people?), this is a good time to speak up.
*** Bug 64265 has been marked as a duplicate of this bug. ***
xorg-x11-6.7.0-r2 is fixed. It needs to reach: "x86 sparc alpha arm hppa mips ppc64 ppc amd64 ia64" xorg-x11-6.8.0-r1 is fixed. It needs to reach: "~x86 ~amd64 ~ppc ~mips" A fix is forthcoming for xfree. ppc64 is a little out of luck on xorg-6.7.0-r2 because it jumped ahead of the maintainer's arch and stabled. It can opt to tell users to re-merge 6.7.0-r2 or mark 6.8.0-r1 stable.
Apologies, 6.8.0-r1 also needs: ppc64 ~ia64 ~hppa (from 6.7.99.x ebuilds)
xfree-4.3.0-r7 is now a security release. It needs to reach: x86 ppc sparc alpha mips hppa amd64 ia64 (based on -r5 and -r6) Any arches that don't reach stable xfree will no longer have any xfree in portage, because everything else will be pulled.
I've started the ebuilds as ~x86. Could another x86 tester please confirm and mark them stable please?
(Note: The above comment doesn't apply to xorg 6.8)
Arches please test and mark stable: xorg-x11-6.7.0-r2 xorg-x11-6.8.0-r1 xfree-4.3.0-r7 (x86 please test and mark stable) Exact keywords provided by Donnie above.
xorg-x11-6.7.0-r2 marked stable on ppc xorg-x11-6.8.0-r1 not marked stable on ppc, Xorg doesn't start up descently (greenish-white screen) tried install 2 (each time i went back to 6.7.0, and did not change config) won't mark stable untill fixed.
Jochen : you don't need to mark stable xorg-x11-6.8*. To clarify what keywords are needed on security POV : x86, sparc, alpha, arm, hppa, ia64 : stable : (xorg-x11-6.7.0-r2 or xorg-x11-6.8.0-r1) and xfree-4.3.0-r7 ppc : stable : xfree-4.3.0-r7 ~ : xorg-x11-6.8.0-r1 mips,amd64 : stable : (xorg-x11-6.7.0-r2 or xorg-x11-6.8.0-r1) and xfree-4.3.0-r7 ~ : xorg-x11-6.8.0-r1 ppc64 : all set, though they could try to mark xorg-x11-6.8.0-r1 stable to cover for people with package.unmasked xorgs. When x86,sparc,ppc and amd64 wil have the required stable keywords, the GLSA will go out. Arches not stable-izing xfree-4.3.0-r7 will in effect deprecate xfree on their arches since the GLSA will instruct xfree users to migrate and all old xfree versions will be package-masked or retired.
marked xorg-x11-6.8.0-r1.ebuild unstable as discussed in PPC meetings we won't support XFree anymore on ppc.
sparc needs sparc-specific patches applied for both xfree & xorg-6.8.0-r1 (patches provided for both), and xfree is deprecated in favor of xorg because of libGL problems. I'll verify for sparc later, but right now, as far as I know, 1. xfree-4.3.0 will not run anything requiring libGL (without patches to libGL & Mesa); 2. xorg-6.8.0 will not run on any 2.4.xx kernel if the user has sparc keyboard, nor will it build at all on some sparc32 systems without some ebuild patching (or equivalent). So xfree is not stable, and the most xorg-6.8.0-<anything> could get from sparc is a ~sparc, until I get feedback from other sparc people to the contrary.
ppc is done. Ferris : if you can mark xorg-x11-6.7.0-r2 stable on sparc and xfree support is deprecated, that's all we need as far as security is concerned.
The following bugs needs to be addressed before 6.8.0-r1 can go stable on x86, and possibly other arches. #63548 #63567 #63647 #63732 #63759 #63795 #63924 #63890 #64129 #64377 There may be more, I only did a quick scim.
I'm building xorg-x11-6.7.0-r2 now to make sure it actually builds. Then I'll mark it ~sparc for a couple days, then go stable. (We were hoping to go from ...-r1 to 6.8.0 because once 6.8 gets built, it is a better choice for sparc (performance issues). But it won't build successfully for all systems without some ebuild help. That's what Bug 63994 is about, mostly. I suppose I should have added it to the blocker list.) Anyway, #63994 should be part of Comment 18's list, as a summary of all sparc issues.
Ian, we're not stabling 6.8.0 on x86. We're ~arch'ing it. I thought I made that clear above. The only arch I would suggest stables 6.8 is ppc64, because that's the only way they can get an automatic upgrade to a "safe" ebuild.
i have no problems with xfree being dropped for amd64. we dont support it anymore anyways... at all. actually, i think i should ~amd64 all current xfree ebuilds just to make sure that point gets across. xorg 6.7.0-r2 stable on amd64
6.7.0-r2 has ~sparc keyword now. Testing and feedback required before it can go stable. We (sparc) prefer 6.8.0-r1, awaiting some ebuild changes to permit clean build, install, and actual use. (Comments 16, 19 above).
Marked 6.7.0-r2 and 6.8.0-r1 ebuilds stable and testing on mips, respectively. As for xfree, it is deprecated. Xorg-x11 is the default in our profile, so I say let xfree die.
Alpha done.
Update on stable need : Arches still needing xorg-x11-6.7.0-r2 stable (or 6.8.0-r1 if you prefer this version) : x86, sparc, ia64 Arches still needing to mark stable xfree-4.3.0-r7 or officially decide it is deprecated : x86, sparc, hppa, ia64 Arches that have already declared xfree deprecated : ppc, amd64, mips
xorg-x11 is already the default on hppa and xfree is considered deprecated. Does anything needs to be done into the cvs to deprecated xfree besides changing the default virtual ?
Also for sparc, xorg-x11 is the default and xfree is deprecated. Otherwise, comments regarding xorg are unchanged: 6.8.0-r1 is awaiting ebuild changes and 6.7.0-r2 is ~sparc for testing. (Comments 19, 22, etc.)
Our daily update summary for sparc: 1. xfree is no longer supported (hasn't been, really, since late May). 2. xorg-x11-6.7.0-r2 is ~sparc for testing; guaranteed to FAIL on hardened systems (xorg issues, not toolchain). Marking this stable would have the curious meaning "stable for sparc unless for you it isn't". 3. xorg-x11-6.8.0-r1 seems fine so far, but cannot get any sort of sparc keyword withoug ebuild help (documented reasons all over the place). I can commit the ebuild changes, x11 herd can commit them, but until they are there, 6.8.0-r1 seems to be in the state "this is the best fix, and you (sparc people) should plan to use it, except if you build it, it probably won't work for you unless you fix the ebuild by hand first". Sorry to keep beating this, but I hope you see our difficulty.
Ferris, about your point 2 above : xorg-x11-6.7.0-r1 is marked stable on sparc. I suppose it has the same xorg/hardened issues as xorg-x11-6.7.0-r2 ? If this is really the case, then it should be marked stable anyway. Security stable marks follow this rule : if it doesn't work worse than the previous stable one, it should be marked stable even if there are unfixed known bugs. So, unless those xorg/hardened problems are new to 6.7.0-r2, this version should be marked stable.
Koon, problem comes in because the option to harden gcc came after xorg-x11-6.7.0-r1. Anyone who chose to harden will be asked to upgrade from a working xorg to a for-sure not working one unless we provide the 6.8.0-r1 option. A new installation would run into the problem this way only: 1. Install; 2. Rebuild hardened; 3. Build xorg-x11 An existing (running hardened system) runs into the problem this way: 1. Upgrade xorg-x11 Since 6.8.0-r1 does not have the problem, we MUCH prefer that alternative. We don't know if this is much of a problem in practice, but would prefer not to find out.
Let me add a line: 6.7.0-r2 just got ~sparc, and we need minimal cofirmation it runs OK unhardened. It can go stable much faster if the 6.8.0-r1 can go ~sparc as well.
I'll try to get your 6.8 changes in ASAP, Ferris, but I've been quite busy the past few days. Maybe tonight I can.
Donnie, Thanks a lot. I just applied the patch on Bug 63994 to current xorg-x11-6.8.0-r1.ebuild as test. One piece is now off by 3 lines, otherwise it applied cleanly. I used it to build on a hardened kernel-2.4.27 system. Build, install went with no problems, and that system is now happily running 6.8.0-r1 antaresia cf # uname -a Linux antaresia.inforead.com 2.4.27-sparc-r1 #1 SMP Thu Sep 9 19:01:42 UTC 2004 sparc64 sun4u TI UltraSparc II (BlackBird) GNU/Linux Mon Sep 20 16:25:08 2004 --> x11-base/xorg-x11-6.8.0-r1 ============== From the Xorg.o.log ============== X Window System Version 6.8.0 Release Date: 8 September 2004 X Protocol Version 11, Revision 0, Release 6.8 Build Operating System: Linux 2.4.27-sparc-r1 sparc64 [ELF] Current Operating System: Linux antaresia.inforead.com 2.4.27-sparc-r1 #1 SMP Thu Sep 9 19:01:4 2 UTC 2004 sparc64 Build Date: 20 September 2004
For sparc, xorg-x11-6.8.0-r1 now is also ~sparc for testing. We'll decide shortly which version (6.7.0-r2, 6.8.0-r1) we want to be considered stable and mark it so. (I personally favor 6.8.0-r1, but we still await user feedback.)
Ferris: waiting for your decision. Someone (x86 team ? X maintainers ?) should also mark stable both xfree-4.3.0-r7 and xorg-x11-6.7.0-r2 for x86.
I guess I can assume it's been tested at this point. Stabled on x86.
Just a little note: ALWAYS make a ChangeLog entry for things in x11-base. I don't care whether it's keywording or whatever.
Koon, re sparc: It's 99.44% certain to be 6.8.0-r1 stable. Please bear with us for a couple more days, because: (1) Thanks to support from xorg (ajax) and x11 herd (spyderous), we now seem to have a clean xorg-x11-6.8.0-r1.ebuild. So, we would like to avoid 6.7.0-r2 if possible (no one is using it). (2) Because of hardware limitations, one or two tests have to wait a couple days (where "couple" means "not more than 3"). (3) Because the build cycle takes so long on sparc, we need to give anyone inclined to test a day at least to build & verify, once it becomes possible. Later today I will distribute a notice to the world to the effect that "If you've got something against xorg-x11-6.8.0-r1, your chance to make your objections count will end by some time this weekend."
Ferris: we're already two days late in our GLSA release (target delay for this kind of vulnerability is 5 days), so the sooner the better.
*** Bug 65112 has been marked as a duplicate of this bug. ***
xorg-x11-6.8.0-r1 is stable for sparc.
GLSA 200409-34
*** Bug 73122 has been marked as a duplicate of this bug. ***