So I would assume that this should have been caught by running the tests before making the release. Or whoever ran the tests had them passing due to build artifacts of previous builds.
Perl will not install if any of its tests fail after it's built. I'm surprised that PHP's test suite isn't run on the user's box after building it, allowing end users to "double check" the release process.
In fact, it is. Just type make test. There are thousands of unit tests and it takes a long time. I generally run it and expect a 98% passing rate. If it's below that, I might have an issue. One or two failing tests will never get noticed.
It seems like they add tests for bugs before actually fixing the bugs. I can see that being useful, but they need to do a better job of marking which bugs are ignorable and which are not.
This is a an open source project - anyone want to volunteer?
http://rubyspec.org/ is the language "spec" that most ruby implementations of note, jruby/rubinius/mri, use to test that they are compliant.
I couldn't find a page with automatic tests running against each implementations head/master branch. But I do see crypt() like specs in there:
https://github.com/rubyspec/rubyspec.git
I would like to say that I would never release code with a failing test, but in truth, my NSNMP module on CPAN has a test that fails occasionally due to some kind of race condition that I've never bothered to fix, because I kind of abandoned NSNMP when I stopped doing any SNMP work in I think 2005. I get email about it from CPANTS every week, and have been since at least 2005.
Now that I've made my confession, I think that this is the latest piece of evidence in a long line showing that the PHP core team just doesn't know how to program. See also this horrorshow that is the list of attempted fixes for an integer overflow vulnerability in 2007: http://use.perl.org/~Aristotle/journal/33448 and this complete freshman-level lack of comprehension of C: http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=34.... And of course there are the evidences of incompetence permanently enshrined in the language, like the fact that "a ? b : c ? d : e" parses incorrectly as "(a ? b : c) ? d : e", but those could simply mean that Rasmus didn't know how to program when he was first designing PHP.
Nevertheless, it must be said that PHP is an incredibly useful piece of software. It clearly shows that intelligence and even basic programming competence are not sufficient or even necessary to build great software. You can do it on sisu alone, and without sisu you can't do it.
This isn't the first time a major bug has been introduced and found shortly after release. How do these major bugs get past testing? Does PHP have poor test coverage? This bug would have been found pretty quickly with basic unit testing.
Not identifying this bug was the result of an (in my opinion) egregious human error. PHP has decent test coverage, and this issue does cause the current tests to fail. I really don't know how this was missed.
How can I get important information like this delivered to my inbox?
I'm serious. Without seeing this here, I might have used YUM to upgrade to the latest version (5.3.7) like I often do. I get the php-announce emails telling me that a new version is available, but nothing telling me when a problem like this emerges.
I think the answer is that this announcement should go out in php-announce. Maybe it will later today.
I really enjoy PHP: I learned on it and in doing so became familiar with its numerous idiosyncrasies. However, and I know this is a weird sentiment, I'm waiting for it to fall out of favor. Then, hopefully, most everybody new to programming/scripting will move on and the community supporting PHP will be pared down. The release cycle will slow, and the gains the language has made can be consolidated and stabilized.
But that's me: I'd rather code in a quiet backwater (e.g. PHP in the future, when everyone has moved on) than be screaming along the cutting edge. Such a goal is definitely the opposite of many.
PHP isn't a quiet backwater, it's a cutting-edge when you should have stable, well-tested code (security-related functions like crypt()), and a backwater when you want to be cutting-edge (object-oriented and functional paradigms).
No, I'm not serious. But if everyone wakes up for a second, checks if they are vulnerable and maybe, accidentally stumbles upon 'Why you don't want to use MD5 for your authentication' posts.. Wouldn't the world be a better place tomorrow?
crypt()'s MD5 is salted and iterated and therefore perfectly adequate to use for your authentication. Just not in PHP 5.3.7. bcrypt() or scrypt() might be better, but crypt() with MD5 is perfectly adequate.
Are you sure it's iterated? I just checked the manual for crypt() and it just says it's MD5 with a salt, but it could be a failure of the documentation.
Of course I don't want to advocate using MD5, even iterated a thousand times, for both of the reasons you state. There are better alternatives. scrypt appears to be one of them, and if it stands up to analysis, it's better than PBKDF2 and bcrypt, which in turn are better than MD5-crypt.
However, MD5 iterated 1000 times is still 1000 times better than MD5 iterated once (which an alarming number of codebases still use!) and the vulnerabilities that have been published in MD5 are not sufficient to speed up an attack on an MD5-crypted password file.
So MD5-crypt is still vastly preferable to many alternatives, including traditional Unix crypt(), even though MD5 has been broken and DES hasn't.
Get ready for some WTF-ery
Crypt takes an optional salt.
If that value is an MD5 hash it is prefixed with the chars $1$ to tell the underlying crypt(3) function to use Modular Crypt Format[1].
MCF is an ad-hoc cruft because the orginal crypt() is weak.
Anyway guess who did it :
"let's use strlcpy/strlcat instead for these static string copies" - Rasmus
I guess that's Lerdorf himself
Whoever it was also didn't check the return values for error. Strlcat returns the length of the new string which might not be the same as strlen(dst) + strlen(src).
"I'm not a real programmer. I throw together things until it works then I move on." - Rasmus Lerdorf
Interesting: Their build server has a failing test for crypt: http://gcov.php.net/viewer.php?version=PHP_5_3&func=test...
So I would assume that this should have been caught by running the tests before making the release. Or whoever ran the tests had them passing due to build artifacts of previous builds.
Or there are just too many tests that fail regularly: http://gcov.php.net/viewer.php?version=PHP_5_3&func=test... - when you have 201 failing tests, one more probably isn't going to cause any concern.