Ahh, see, this would be the logical course of action... but this is the X server we're talking about here. We've got to keep EVERYTHING and we've got to keep it UNTOUCHED in case something we do accidentally breaks the behavior in a super out-of-the-way corner case.
Originally Posted by uid313
It made me sad when Wayland adopted a similar approach, since we've all seen how that worked out...
I've been thinking that a 2-release (major release, not point releases) lifespan of things you didn't actually want would be smarter.
E.g. you put in X feature in 2.0 but almost nobody used it (leading to nobody maintaining it) and it was starting to interfere with other things, you would be forced to wait until version 4.0 until you could rip it out, but you COULD rip it out.
Depending on the project, that 2.0 <--> 4.0 wait time could be super long or super short. On a display server, it could be a very long wait, but that just gives the complainers less to complain about.
Mandatory 30c3 reference
If I understand this correctly, this is just a build time "solution". It's better than using a VM based language if you only need memory safety (supposedly, I can't really say as I haven't worked with such languages), but still, this has nothing to do with actually fixing those bugs.
Originally Posted by YoungManKlaus
Maybe one of those hundreds of bugs has something to do with why AMD can't fix that annoying xscreensaver crash-the one where X freezes as soon as you move the mouse.
The cppcheck developers are doing that on the Debian package sources now.
Originally Posted by uid313
Scan results: http://cppcheck.sourceforge.net/devi...ort/daca2.html
That's so last week: http://www.phoronix.com/scan.php?pag...tem&px=MTU1NzA - Michael even included a link to that story in this one to remind you.
Originally Posted by sobkas
He's already got a fulltime job finding bugs, as the Director of Penetration Testing for IOActive.
Originally Posted by hajj_3
Right, the way XAA was kept forever to avoid breaking the handful of people running on decade old cards with no one who cares enough to update/maintain their driver. Oh wait, sorry, that's a different “flame the X developers” thread on Phoronix.
Originally Posted by Daktyl198
X.Org removes functionality when it's appropriate, but a one line fix is a far more acceptable change for distros to take in as a security patch to existing releases than ripping out code people may be using. I hope we can drop this BDF code in the future and replace it with calls to the FreeType code; but as part of a normal development cycle, where there's time to test that everything that linked to it is working without it, and it can be reviewed publicly, and adopted by distros in their dev cycles, not as a urgent security fix reviewed in private by just the security team with no chance for anyone else to know it's coming.
I'm the guy who ends up backporting CVE fixes from X.org to "tinyX", which is a little project (based on a modified xorg-server 1.2.??) used for some of the smallest Puppy-related graphical live cds.
So I've got a few observations:
-A lot more of the code is unchanged than I would have expected.
-This means that backporting fixes is frequently trivial.
-On the other hand, when I read it I'm not surprised by the number of bugs or the static nature of the code. It seems to be most fun when you have a little bit of a masochistic streak...
-Despite the reputation X has, it's fairly quick to backport all the fixes.
In at least one case, the bug had once been one branch of an #ifdef that had since been deleted; the fix was to replace it with the other branch.
Now, since alanc mentioned FreeType:
Year before last, they had CVE-2012-1126 through CVE-2012-1144, and CVE-2012-5668 through CVE-2012-5670.
That's 22 CVEs in one year.
And they had a number in 2010 and 2011.
So I'm not sure if replacing libXfont with FreeType would be a gain.
libXfont already uses FreeType to render OpenType, TrueType, and PostScript fonts, so using it for another font type isn't going to be much of a change either.
Originally Posted by Ibidem