And there's a long list of languages immune to buffer overflows (this is mostly a glaring hole in C/C++).

We'll release full detail tomorrow (Monday) at 16:00 GMT, after essentially the entire world has had a chance to go into work Monday morning, see the alert message, and shutdown/upgrade.

I'm sorry but you are completely wrong here.

You have to be god-like to not create security vulnerabilities in significantly C/C++ software.  'Direct' buffer overflows can be avoided by littering your code with meticulous boiler plate (and praying you haven't made a mistake somewhere).  But integer overflows leading to buffer overflows are so hopelessly trickly that I have no faith in any C/C++ being safe.

Java/Python/Ruby/Lisp buffer overflows simply don't exist... a huge class of exploit eradicated by language choice.  And there's a long list of languages immune to buffer overflows (this is mostly a glaring hole in C/C++).  Look up US military/intelligence mandates about language choice.  C/C++ is so bad that it should be immediately abandoned and _never_ used for _anything_.  Why do you think computer security is such a disaster (it was all C/C++ until the recent xss/xsrf/sql havoc - and that too is a design flaw).

That you think "this is nonsense" means that your own code is already insecure, and you just don't know it.

FYI, Windows binaries from the 0.6.0rc4 source (in git) will not get you a fixed build.

Why's that?  The v0.6.0rc4 tag includes the -lmingwthrd fix.

When I first saw your post I figured I must have guessed wrongly what the update was all about, because the changes for safe multi-threading in mingw were included in the rc4 source.