Slashdot Mirror

the same Kurt Roeckx had to patch the original infamous May/2006 patch , because he put nested comments and md_rand.c didn't compile :

http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/crypto/rand/md_rand.c?rev=173&r1=167&r2=173

This is the complete revision history of md_rand.c at debian, including the last fix by the same Kurt Roeckx that reads

"ssleay_rand_add() really needs to call MD_Update() for buf."

http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/crypto/rand/md_rand.c?rev=300&r1=173&view=log

ooopss .... frightening

I have to repeat what this paper says:

" In a narrow sense, the security flaw we found in the Netscape browser serves merely as an anecdote to emphasize the difficulty of generating cryptographically strong random numbers. But there's a broader moral to the story. The security community has painfully learned that small bugs in a security-critical module of a software system can have serious consequences, and that such errors are easy to commit. The only way to catch these mistakes is to expose the source code to scrutiny by security experts.

Peer review is essential to the development of any secure software. Netscape did not encourage outside auditing or peer review of its software-and that goes against everything the security industry has learned from past mistakes. By extension, without peer review and intense outside scrutiny of Netscape's software at the source-code level, there is simply no way consumers can know where there will be future security problems with Netscape's products. "

http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html

Debian: learn from this !!!

and Kurt Roeckx, don't touch any code of security packages any more ( and yes, you can't nest comments if you want to build md_rand.c , perhaps you should slow down before pushing the "commit changes" button, at least until debian leaders start to put in place tighter and scrict testing-before-commit policies )

the same Kurt Roeckx had to patch the original infamous May/2006 patch , because he put nested comments and md_rand.c didn't compile :

http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/crypto/rand/md_rand.c?rev=173&r1=167&r2=173

This is the complete revision history of md_rand.c at debian, including the last fix by the same Kurt Roeckx that reads

"ssleay_rand_add() really needs to call MD_Update() for buf."

http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/crypto/rand/md_rand.c?rev=300&r1=173&view=log

ooopss .... frightening

I have to repeat what this paper says:

" In a narrow sense, the security flaw we found in the Netscape browser serves merely as an anecdote to emphasize the difficulty of generating cryptographically strong random numbers. But there's a broader moral to the story. The security community has painfully learned that small bugs in a security-critical module of a software system can have serious consequences, and that such errors are easy to commit. The only way to catch these mistakes is to expose the source code to scrutiny by security experts.

Peer review is essential to the development of any secure software. Netscape did not encourage outside auditing or peer review of its software-and that goes against everything the security industry has learned from past mistakes. By extension, without peer review and intense outside scrutiny of Netscape's software at the source-code level, there is simply no way consumers can know where there will be future security problems with Netscape's products. "

http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html

Debian: learn from this !!!

and Kurt Roeckx, don't touch any code of security packages any more ( and yes, you can't nest comments if you want to build md_rand.c , perhaps you should slow down before pushing the "commit changes" button, at least until debian leaders start to put in place tighter and scrict testing-before-commit policies )

That is pretty much completely wrong.

OpenSSL definitely used uninitialized memory for randomness. This was optional, and there was a flag to turn it off during compilation, because it made valgrind complain.

However, Debian did not use this flag, but tried to comment the offending lines out themselves. However, they commented out more than they should, and rendered the whole code non-functional.

Here is the actual patch:

http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/rand/md_rand.c?rev=141&view=diff&r1=141&r2=140&p1=openssl/trunk/rand/md_rand.c&p2=/openssl/trunk/rand/md_rand.c

Note the lack of memset() or XOR loops.

You will want to download this tool to check each system:

http://security.debian.org/project/extra/dowkd/dowkd.pl.gz

To use it:

$ perl dowkd.pl user

$ perl dowkd.pl host localhost

See http://lists.debian.org/debian-security-announce/2008/msg00152.html

Why isn't such a scan isn't part of the package update? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481106

You will want to download this tool to check each system:

http://security.debian.org/project/extra/dowkd/dowkd.pl.gz

To use it:

$ perl dowkd.pl user

$ perl dowkd.pl host localhost

See http://lists.debian.org/debian-security-announce/2008/msg00152.html

Why isn't such a scan isn't part of the package update? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481106

You will want to download this tool to check each system:

http://security.debian.org/project/extra/dowkd/dowkd.pl.gz

To use it:

$ perl dowkd.pl user

$ perl dowkd.pl host localhost

See http://lists.debian.org/debian-security-announce/2008/msg00152.html

Why isn't such a scan isn't part of the package update? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481106

It is even worse than this. Passwords that were used on a server with a weak DSA key may be compromised, as well:

From http://wiki.debian.org/SSLkeys

The DSA contains a link to http://security.debian.org/project/extra/dowkd/dowkd.pl.gz, which can examine an ssh authorized_keys file (among other things) and let you know which, if any, keys are weak.

By what I've seen of the RIAA, they could make good use of the choke on a bucket of cocks function.

Interestingly, another source of compromised security is seeding too often. http://lists.debian.org/debian-security-announce/2008/msg00152.html is an example of a vulnerability caused by seeding the random number generator with the current time right before use.

That's not a case of seeding too often, that's a case of using a crappy seed

From this log: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516
It looks like openssl is pulling in "entropy" from uninitialized memory, causing valigrind to complain. The debian maintainer "fixed" this issue by memsetting the buffer to zero.

My question is, wouldn't I see the same behavior using grsecurity to scrub deallocated memory? From what I am seeing, this looks much more like the fault of the openssl team.

Does Debian have a formal procedure for investigating maintainers who create serious vulnerabilities like this?

If so, does one of the paths of the investigation involve the police or a lawsuit option?

The patch that broke it was checked in by Kurt Roeckx [kroeckx@debian.org]. Don't know if he broke it or if he was just the gatekeeper for checkins. See:

http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/rand/md_rand.c?rev=141&view=diff&r1=141&r2=140&p1=openssl/trunk/rand/md_rand.c&p2=/openssl/trunk/rand/md_rand.c which shows the change that introduced the bug; and its parent node:
http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/rand/?rev=141#dirlist which shows the maintainer responsible.

From looking at this patch, I think this is what happened. valgrind complained about a rather unusual coding convention in ssleay_rand_bytes. This is a function that returns random data into a buffer. However, before writing into the buffer, it reads from the buffer and incorporates the old contents into the internal random state. valgrind complained about this use of an output buffer for input. Normally you would never want to use potentially uninitialized data like this, but in this case it is OK as all that is being done is the data is being folded into the random state. In the worst case, this can't hurt, and maybe it will help, if the old data had some randomness.

Anyway, valgrind complained about it, and the maintainer commented out the use of the buffer. That would actually be OK, it is not a big deal. But the implementor made a mistake, and also commented out another similar usage, in a different function, ssleay_rand_add. This was a huge mistake, as the purpose of ssleay_rand_add is to add randomness into the random state. In that function, buf is an INPUT buffer, and adding it into the random state is perfectly legitimate, in fact it is the whole purpose of the function. But apparently because it looked similar to the questionable usage in ssleay_rand_bytes, the maintainer commented out the code in ssleay_rand_add at the same time. (I don't know whether valgrind also complained about this second usage, but if so, it was mistaken. I think it's more likely that the maintainer just got fooled and over-generalized from the valgrind complaint.)

So the whole thing was an attempt to clean up code and remove warnings, but the fix accidentally broke a crucial piece of functionality, rendering ssleay_rand_add completely non-functional. So any attempt to add randomness into the RNG state, such as for seeding purposes, is ineffective. The random state ends up with much less variability, and therefore all the crypto is weak. As Bruce Schneier points out, bad crypto looks much the same as good crypto, so it took this long to notice it.

Hats off to the reviewer who picked up on the problem. Don't know who it was, but the same Kurt Roeckx [kroeckx@debian.org] checked in the fix.

The patch that broke it was checked in by Kurt Roeckx [kroeckx@debian.org]. Don't know if he broke it or if he was just the gatekeeper for checkins. See:

http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/rand/md_rand.c?rev=141&view=diff&r1=141&r2=140&p1=openssl/trunk/rand/md_rand.c&p2=/openssl/trunk/rand/md_rand.c which shows the change that introduced the bug; and its parent node:
http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/rand/?rev=141#dirlist which shows the maintainer responsible.

From looking at this patch, I think this is what happened. valgrind complained about a rather unusual coding convention in ssleay_rand_bytes. This is a function that returns random data into a buffer. However, before writing into the buffer, it reads from the buffer and incorporates the old contents into the internal random state. valgrind complained about this use of an output buffer for input. Normally you would never want to use potentially uninitialized data like this, but in this case it is OK as all that is being done is the data is being folded into the random state. In the worst case, this can't hurt, and maybe it will help, if the old data had some randomness.

Anyway, valgrind complained about it, and the maintainer commented out the use of the buffer. That would actually be OK, it is not a big deal. But the implementor made a mistake, and also commented out another similar usage, in a different function, ssleay_rand_add. This was a huge mistake, as the purpose of ssleay_rand_add is to add randomness into the random state. In that function, buf is an INPUT buffer, and adding it into the random state is perfectly legitimate, in fact it is the whole purpose of the function. But apparently because it looked similar to the questionable usage in ssleay_rand_bytes, the maintainer commented out the code in ssleay_rand_add at the same time. (I don't know whether valgrind also complained about this second usage, but if so, it was mistaken. I think it's more likely that the maintainer just got fooled and over-generalized from the valgrind complaint.)

So the whole thing was an attempt to clean up code and remove warnings, but the fix accidentally broke a crucial piece of functionality, rendering ssleay_rand_add completely non-functional. So any attempt to add randomness into the RNG state, such as for seeding purposes, is ineffective. The random state ends up with much less variability, and therefore all the crypto is weak. As Bruce Schneier points out, bad crypto looks much the same as good crypto, so it took this long to notice it.

Hats off to the reviewer who picked up on the problem. Don't know who it was, but the same Kurt Roeckx [kroeckx@debian.org] checked in the fix.

The original change was tracked in the debian Bugtracking system at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516
The offending patch: http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/rand/md_rand.c?rev=141&view=diff&r1=141&r2=140&p1=openssl/trunk/rand/md_rand.c&p2=/openssl/trunk/rand/md_rand.c
The fix: http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/crypto/rand/md_rand.c?rev=300&view=diff&r1=300&r2=299&p1=openssl/trunk/crypto/rand/md_rand.c&p2=/openssl/trunk/crypto/rand/md_rand.c

The original change was tracked in the debian Bugtracking system at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516
The offending patch: http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/rand/md_rand.c?rev=141&view=diff&r1=141&r2=140&p1=openssl/trunk/rand/md_rand.c&p2=/openssl/trunk/rand/md_rand.c
The fix: http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/crypto/rand/md_rand.c?rev=300&view=diff&r1=300&r2=299&p1=openssl/trunk/crypto/rand/md_rand.c&p2=/openssl/trunk/crypto/rand/md_rand.c

The original change was tracked in the debian Bugtracking system at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516
The offending patch: http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/rand/md_rand.c?rev=141&view=diff&r1=141&r2=140&p1=openssl/trunk/rand/md_rand.c&p2=/openssl/trunk/rand/md_rand.c
The fix: http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/crypto/rand/md_rand.c?rev=300&view=diff&r1=300&r2=299&p1=openssl/trunk/crypto/rand/md_rand.c&p2=/openssl/trunk/crypto/rand/md_rand.c

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516

Check out this bug report and tell me they weren't just being arrogant:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516

Says the first comment to the patch, in regards to what is being reversed:
"What it's doing is adding uninitialised numbers to the pool to create random numbers."

OpenSSL having more-random numbers vs. Valgrind looking good. And Valgrind won?

The consensus in the bug report seems to be not to do it, but then someone adds the patch anyways.

It was reading from initialized memory to for the seed value, leading to valgrind warnings. See the original Debian bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516

Interestingly, another source of compromised security is seeding too often.

http://lists.debian.org/debian-security-announce/2008/msg00152.html

is an example of a vulnerability caused by seeding the random number generator with the current time right before use.

All he's waiting for now is DNF.

I rather like this one that I saw at the weekend. Sounds like an unpleasant way to go.

For reference: The Debian installation guide.

Any distro whose install guide needs to contain a section "Setting Up Your System To Use E-Mail" I think should be fairly disqualified. I think "desktop" distros should be those that are basically plug and play (I've never used Debian myself, so if I'm wrong here let me know). Don't get me wrong though on one account, my distro of choice is Arch, and I wouldn't really call that a desktop distro either; nothing wrong with that.

Does it take its adherence to free software to the point of leaving us in a ghetto where we cannot do the things we could with other distros?

Yep, I suspect it does. The FSF list skips even Debian, a group so committed to FOSS that they release Firefox as Iceweasel due to their concerns regarding non-free images. You've got to wonder how restricted your Linux actually has to be to make the FSF recommended list.

The one thing I've never been able to get to grips with about the linux desktops are the fonts.

Remember WindowMaker? One day the new WindowMaker developers decided that an option named "AUTOCIRCULATE" made more sense if it meant something completely different from what it had for years. And support for the old option, which was one of the easiest ways to change focus without raising a window to the top, disappeared. Around the same time the Debian wmaker package was also stripped of ALL KEYBOARD SHORTCUTS in the name of "correctness". Complaints were lodged, rebutted, parried, delayed and now it seems the package has fallen into deep disrepair. The current maintainer says he will try to reverse this brain damage, but progress has yet to take hold. I think most people gave up and moved on to one of the "chunky"/flashy fisher-price style window managers or blackbox. The lesson? Never "upgrade" unless you have to. Now this POS wmaker version is "release quality" and polluting all branches of Debian, so downgrading is a bitch.

Remember WindowMaker? One day the new WindowMaker developers decided that an option named "AUTOCIRCULATE" made more sense if it meant something completely different from what it had for years. And support for the old option, which was one of the easiest ways to change focus without raising a window to the top, disappeared. Around the same time the Debian wmaker package was also stripped of ALL KEYBOARD SHORTCUTS in the name of "correctness". Complaints were lodged, rebutted, parried, delayed and now it seems the package has fallen into deep disrepair. The current maintainer says he will try to reverse this brain damage, but progress has yet to take hold. I think most people gave up and moved on to one of the "chunky"/flashy fisher-price style window managers or blackbox. The lesson? Never "upgrade" unless you have to. Now this POS wmaker version is "release quality" and polluting all branches of Debian, so downgrading is a bitch.

... and another 308247 on ubuntu, and 79049 on debian, and ...

See the language benchmark shootout for all your implementation comparisons! ;-)

Is this really still accurate?

• VMs have comically bloated memory footprints: between 2x and 30x comparable C programs according to benchmarks: JVM, Mono. Even if you consider memory cheap, smaller is always better because it means fewer bits flying over the bus and better cache utilization.
• VMs stop the world to do garbage collection. Point me to all the articles you want that explain how "it's getting better" and "they've figured out how to make it real-time," but that doesn't change the fact that you're stopping all threads whenever you garbage collect, which is making your latency suffer.

C and C++ are the only game in town for getting the best performance and a small memory footprint and the ability to have the lowest possible latency.

That said, I think that C and C++ are becoming harder to justify when you consider the havoc that memory errors can wreak. It's highly embarrassing to vendors and damaging to their customers when a buffer overflow exploit is discovered. malloc and free, even when used correctly, can still have some forgotten downsides like the memory fragmentation that was discovered in Firefox 2, and took some very smart people a lot of work to address.

What I would like to see is a language that gives the benefits of C and C++ (extremely fast, extremely small memory footprint, and no GC pauses) but that is also immune to C and C++'s weaknesses (memory corruption, memory leaks, memory fragmentation). Yep, I pretty much want to have my cake and eat it too. Why do I think this is possible? I think that the future is to have a fully concurrent, compacting GC. Everyone's telling us we're going to have more cores than we know what to do with soon, right? Well why not use all those extra cores to do GC in the background? Even if it's more expensive on the whole, we barely know what to do with all those extra cores as it is. With this strategy, you could get the performance guarantees and low overhead of C and C++ (on the real, non-GC thread, that is) without having to give up GC or suffer from memory fragmentation.

I'm also not willing to give up the option of dropping to C or C++ (or even assembly language) when it's justified. Mention JNI in a room of Java people and observe them reel in horror -- it's culturally shunned to deviate from "100% pure Java." Maybe this is a good value when you're on a big team of people writing a web app, but for systems and multimedia programming this is silly -- inner loops are inner loops, and some of them can benefit from machine-specific optimization.

Theoretically you could experiment with the fully concurrent GC using an existing language/runtime like Java, but I've sort of given up on the JVM and .NET communities, because they have empirically demonstrated that they culturally have no regard for small memory footprint, low overhead, short startup time, etc. They just don't consider huge memory footprint or ridiculous startup times a problem. This is not to ment

• VMs have comically bloated memory footprints: between 2x and 30x comparable C programs according to benchmarks: JVM, Mono. Even if you consider memory cheap, smaller is always better because it means fewer bits flying over the bus and better cache utilization.
• VMs stop the world to do garbage collection. Point me to all the articles you want that explain how "it's getting better" and "they've figured out how to make it real-time," but that doesn't change the fact that you're stopping all threads whenever you garbage collect, which is making your latency suffer.

C and C++ are the only game in town for getting the best performance and a small memory footprint and the ability to have the lowest possible latency.

That said, I think that C and C++ are becoming harder to justify when you consider the havoc that memory errors can wreak. It's highly embarrassing to vendors and damaging to their customers when a buffer overflow exploit is discovered. malloc and free, even when used correctly, can still have some forgotten downsides like the memory fragmentation that was discovered in Firefox 2, and took some very smart people a lot of work to address.

What I would like to see is a language that gives the benefits of C and C++ (extremely fast, extremely small memory footprint, and no GC pauses) but that is also immune to C and C++'s weaknesses (memory corruption, memory leaks, memory fragmentation). Yep, I pretty much want to have my cake and eat it too. Why do I think this is possible? I think that the future is to have a fully concurrent, compacting GC. Everyone's telling us we're going to have more cores than we know what to do with soon, right? Well why not use all those extra cores to do GC in the background? Even if it's more expensive on the whole, we barely know what to do with all those extra cores as it is. With this strategy, you could get the performance guarantees and low overhead of C and C++ (on the real, non-GC thread, that is) without having to give up GC or suffer from memory fragmentation.

I'm also not willing to give up the option of dropping to C or C++ (or even assembly language) when it's justified. Mention JNI in a room of Java people and observe them reel in horror -- it's culturally shunned to deviate from "100% pure Java." Maybe this is a good value when you're on a big team of people writing a web app, but for systems and multimedia programming this is silly -- inner loops are inner loops, and some of them can benefit from machine-specific optimization.

Theoretically you could experiment with the fully concurrent GC using an existing language/runtime like Java, but I've sort of given up on the JVM and .NET communities, because they have empirically demonstrated that they culturally have no regard for small memory footprint, low overhead, short startup time, etc. They just don't consider huge memory footprint or ridiculous startup times a problem. This is not to ment

D also offers syntax and ease of writing comparable to C#/Java, but is faster, doesn't require VM and compiles to native code linkable with C.

I've tried contributing code, but they're stuck in a cathedral and won't acknowledge me.

I hear ya...I've better luck with the Debian Hurd project, give them a shot:

http://www.debian.org/ports/hurd/

If it's been a while, you might be pleasantly surprised: you can get a decent GNU/Hurd install going without too much trouble, there are things happening, development-wise (including possible "summer of code" participation) and so on.

Good luck.

DebTorrent is at work on precisely this.

According to this: http://packages.debian.org/vlc
vlc is in sarge too.

(Or indeed, Here, which really lets you do it yourself)

*Ahem*

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=gcc&lang2=perl

Perl is only fast when it is used to glue components written in C together. Try to implement something actually CPU intensive in actual perl and it will be much, much slower than any C implementation.

Note, this is not to bash perl, i love it and use it almost every day, but it is by no means a speed devil.

Even java 6 beats perl most of the time:

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=java&lang2=perl

But at a serious memory cost.

*Ahem*

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=gcc&lang2=perl

Perl is only fast when it is used to glue components written in C together. Try to implement something actually CPU intensive in actual perl and it will be much, much slower than any C implementation.

Note, this is not to bash perl, i love it and use it almost every day, but it is by no means a speed devil.

Even java 6 beats perl most of the time:

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=java&lang2=perl

But at a serious memory cost.

On the one hand, it's nice to see some analysis on more loosely organized software projects. It's definitely not something that the average corporate sponsored University department would do.

It's also funny to see how short most enthusiasts memories are. Pre-Sarge, Debian was being criticized for everything under the sun.

As an off-topic FYI, Debian Testing is in fine shape for a KDE desktop. I'm running two simple servers on testing and there are no show-stopper bugs. Get your Beta installation disk today! http://www.debian.org/devel/debian-installer/

Was Theo on holiday for two months? Because according to the Debian bug, he was notified on February 3rd.

I won't debate whether full or responsible disclosure would be best for everyone.

I will suggest that there should be consistency & Debian believes in responsible disclosure.

Debian maintains a private security reporting mechanism & tells developers that some security bugs may be private for some length of time. Indeed, the Debian dev who closed that issue expressed apologies for not contacting the appropriate person.

Even those who do not believe in responsible disclosure will usually have the good manners to at least simultaneously contact developers and go public.

"Slipstream" is a somewhat noxiously overblown word for "updated installer image", don't you think? And all the while you scoff at those who don't care to complete the mind-bogglingly long number of steps needed to "slipstream" basic updates into an installer, Linux users have cast off that albatross entirely and simply install the right versions the first time around.

Windows still needs some really remedial rehabilitation of its package management "capabilities", and what you lot call "slipstreaming" just sounds like some long-abandoned ritual to us. I've even heard that Windows guys still primarily use the "executable installer" method of software distribution -- is that actually true? It sounded made-up to me when I heard it; probably just an exaggeration from some half-cocked Linux zealots!

I know I posted roughly this comment in the last GSoC Slashdot announcement but I've been told the information is really useful and some people might have missed it.

On the note about how GSoC effects our project you should take a look at our web stats since we where announced as a GSoC mentor organisation. The increase has been massive!

Google has been very good to the Open Source gaming community again this year, there are a total of 7 game projects and 5 game related projects.

The following game projects have been accepted,

• Battle for Wesnoth (ideas), a very cool tu rn based strategy game in the theme of Heroes of Might and Magic.
• BZFlag (ideas), the cla ssic tank first person shooter game. One of the oldest open source games around!
• Linden Lab (ideas), the makers of Second Life the largest "almost game like" online universe.
• ScummVM (ideas), an engine whic h lets you play all the classic Lucas Arts games and many more!
• Thousand Parsec (ideas), a framework fo r building 4x empire building games. Been around since 2001 and growing quickly.
• Tux4Kids (ideas), a group of mul ti-platform open source educational games for children.
• WorldForge (ideas), one of the ori ginal open source MMORPG which has even been mentioned on Slashdot multiple times (original called Altima).

The Summer of Code had a huge impact my own project, Thousand Parsec and I hope that it will again have a significant positive impact. GSoC 2007 helped us develop a number of core utilities that the main developers just would not have time to do. These projects should substantially increase the productivity of new contributors and lower the barrier to entry into development. The huge amount of web traffic brought to our website from just being a mentor organisation can clearly be seen in our web statistics.

This year we are planning to concentrate on improving the player experience. The two ways for achieving this is to create more full and interesting games (rulesets) and making the game clients more attractive and easier to access (such as a web-based client and improving the desktop client).

Out of the three students that where selected last year, two passed their final evaluations. The code that the students produced was of both a high quality and quantity.

One of the students projects, the RFTS clone ruleset, is now one of the most complete and popular of our games (rulesets). The student has continued to help with its development and is now currently considering being a mentor this year.

The other successful student made over 220 commits and produced 28,824 lines of code, more than some of our other long term project members! He has developed a

do you know of anything that was broken besides SBCL (which was how this was discovered in the first place).

BTW I belive the intention of debian is to attack this problem from all sides. Afaict SBCL is being changed to keep the direction flag set for as short a time as possible. gcc is being changed to return to the older less likely to fail behaviour and linux is being changed to do what it should have done in the first place.

This does not affect the users directly, but it is a major pain for integrators/porters. OO.o has a terrible habit of bundling all of the 3rd-party software packages, that it uses, into its own source tree. I'm talking about (probably missed some):

• agg
• bash
• bitstream-vera
• bsh
• bison
• boost
• curl
• db42
• dmake
• expat2
• freetype
• icu
• jpeg
• firefox (or some other Mozilla-based browser)
• libmspack
• libsndfile
• libtextcat
• libwpd
• libxslt
• neon
• nss
• nspr
• python
• sane-backends
• STLport
• unixODBC
• unzip
• vigra
• xmlsec1
• xt
• zip
• zlib

If they could, I'm certain, they would've bundled Java too, but — fortunately — Sun's license prohibits that... Now I realize, that this is done to offer "a single package" to those, who build it on their own, but nobody does. Everybody gets these from their OS' integrators. And the pain for us is enormous, because to force OO.o build to stop its silly ways is a serious undertaking. For some of the above packages there is --with-system-foo configure-flag, but not for all, and the default is to always use the bundled one, so support for the external ones bitrots quickly...

Most of the local builds don't bother and so end up wasting disk space and CPU-time rebuilding packages, which are external to OO.o. The end results are also bloated, duplicating stuff, that's already installed on the users' systems and without bug-fixes, which have already gone into each of the respective package since its most recent "bundling" into OO.o tarballs.

Download a source tarball and see for yourself... Something like: tar tjf OOo_OOG680_m9_source.tar.bz2 | grep 'z$'. No other software project does this on this scale and for good reasons — it is Just Wrong[TM]. OO.o better clean up their act in this respect...