PHP-update 5.3.7 bevat beveiligingsgat

De PHP-ontwikkelaars hebben een waarschuwing uitgegeven waarin dringend wordt aangeraden om de laatste update met versienummer 5.3.7 niet te installeren of te gebruiken. De update zou een ernstige fout bevatten in de crypt()-functie.

Met de crypt()-functie van de scripttaal kan een string versleuteld worden en van een hash worden voorzien. Echter als in PHP-versie 5.3.7 de crypt()-functie wordt aangeroepen met het MD5-algoritme en enkele salt-karakters, dan geeft de functie alleen de salt-karakters terug in plaats van de gewenste hash. Het probleem zou niet optreden als crypt() wordt aangeroepen met het DES- of Blowfish-algoritme, zo meldt de bugreport.

Door de fout in de versleutelingsfunctie wordt door de PHP-ontwikkelaars sterk afgeraden om de update te installeren. Een nieuwe update met versienummer 5.3.8 zou op korte termijn, mogelijk binnen enkele dagen, beschikbaar moeten komen om het probleem met de crypt()-functie te verhelpen. De bug is echter al afgelopen vrijdag verholpen.

Omdat PHP op een groot aantal websites wordt gebruikt, zijn bugs in de scripttaal potentieel gevaarlijk. Om deze gaten te dichten brengen de ontwikkelaars met regelmaat updates uit.

Reacties (82)

[spil]

Gelukkig had ik al een gepatchte versie geïnstalleerd. Volgens FreeBSD ports is dit de oplossing voor het crypt() probleem
[code]
--- ext/standard/php_crypt_r.c.orig 2011-08-22 09:54:16.000000000 +0200
+++ ext/standard/php_crypt_r.c 2011-08-22 09:54:49.000000000 +0200
@@ -382,7 +382,7 @@
/* Now make the output string */
memcpy(passwd, MD5_MAGIC, MD5_MAGIC_LEN);
strlcpy(passwd + MD5_MAGIC_LEN, sp, sl + 1);
- strlcat(passwd, "$", 1);
+ strcat(passwd, "$");

PHP_MD5Final(final, &ctx);
[/code]

[Lima]

De nieuwe versie in FreeBSD heeft dit al gefixed in de 5.3.7_2 normaal. In afwachting...

[Earry]

PHP 5.3.8 staat al online. Verander de download URL maar eens. Hij is alleen nog niet officieel gereleased dmv nieuwsbericht op de site.

[MrR0b3rt]

Het probleem is ook al opgelost:

[2011-08-19 22:50 UTC] [e-mail]
This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

For Windows:

http://windows.php.net/snapshots/

Thank you for the report, and for helping us make PHP better.

fixed, thanks

[FiscBiker]

Als dat lek echt zo gevaarlijk is hadden ze wel iets op de announce mailinglist mogen zetten. Dit is het eerste wat ik er van hoor, terwijl de bug zaterdag volledig uitgeplozen en bevestigd was.

[hostname]

Die announce mailinglist is totaal nutteloos. Nieuwe releases worden ook maar gemiddeld 1 in de 10x daar aangekondigd. RSS feed van php.net volgen is nuttiger.

Overigens kwam het nieuwsbericht pas later omdat er niemand met toegang tot de website van het weekend aanwezig was...

[martin149]

Hoe zou dit eigenlijk gevaarlijk kunnen zijn, zo werkt toch gewoon een functie niet, maar zijn er geen grote problemen. Je kunt op deze manier toch niks hacken. (of heb ik het fout?)

EDIT: Mijn host draait gelukkig nog 5.2.17

[Reactie gewijzigd door martin149 op 24 juli 2024 07:25]

[Jegorex]

Als je nu een account aanmaakt dan zal het wachtwoord in de database alleen de salt zijn.
Vervolgens kun je met elk willekeurig wachtwoord inloggen.

[MSalters]

En, om het erger te maken, als je vervolgens naar 5.3.8 upgrade, dan kan niemand meer inloggen met z'n oude passwoord. De 5.3.8 hash zal namelijk vrijwel nooit (<0.000001%) gelijk zijn aan de 5.3.7 hash. Dus je kunt de T.net nieuwsberichten van volgende week voorspellen: een aantal sites zullen een PW reset aankondigen.

[BRAINLESS01]

Alleen voor nieuwe gebruikers, voor oude gebruikers staat de oude hash nog in de database natuurlijk.

[cyberstalker]

Niet per se. Bestaande gebruikers zullen nu niet meer kunnen inloggen. Een groot deel van deze gebruikers zal vervolgens een nieuw wachtwoord aanvragen.

Dit nieuwe wachtwoord zal vervolgens onjuist worden opgeslagen maar mensen zullen kunnen inloggen. Wanneer de bug dan vervolgens gefixed wordt kunnen mensen weer niet inloggen tot ze wederom een nieuw wachtwoord aanvragen.

[poepkop]

Nou volg ik je niet meer, want een 5.3.6 hash zal hetzelfde zijn als een 5.3.8 hash, het is toch gewoon md5?
Overigens, is md5 niet al achterhaald en kan je niet beter sha gebruiken? Of heeft dit ook invloed op sha?

[Gamebuster]

Md5 en sha1 verschillen niet schokkend veel. bcrypt is goed voor login hashes

[kaneter]

Als crypt() alleen de salt teruggeeft, betekent dit dus in feite dat je op een standaard inlogsysteem dat gebruik maakt van deze functie met elk willekeurig wachtwoord kunt inloggen. Dit geldt natuurlijk niet voor gebruikersaccounts die zijn aangemaakt vóór deze PHP-update.

Edit: spuit11

[Reactie gewijzigd door kaneter op 24 juli 2024 07:25]

[i-chat]

klopt - die gebruikers kunnen gewoon helemaal NIET inloggen...

[Verwijderd]

Die gaan dus wellicht een nieuw wachtwoord instellen dat wél werkt, maar vervolgens werkt élk ander wachtwoord óók.

[Gertjan]

EDIT: Mijn host draait gelukkig nog 5.2.17

"gelukkig"? Zie de releasenotes van PHP 5.3.7:

All PHP users should note that the PHP 5.2 series is NOT supported anymore. All users are strongly encouraged to upgrade to PHP 5.3.7.

PHP 5.3.0 is meer dan twee jaar geleden uitgekomen. Als ik jou was zou ik op zoek naar een host met een beter upgrade-beleid. Nu nog op de 5.2-tak zitten is onverantwoord, zeker gezien het feit dat een upgrade-procedure meestal wel enige tijd met zich meeneemt. Tenzij je host natuurlijk besluit om 's nachts 'eventjes te upgraden'. In dat geval zou ik zeker op zoek gaan naar iets anders ...

[arjankoole]

All PHP users should note that the PHP 5.2 series is NOT supported anymore. All users are strongly encouraged to upgrade to PHP 5.3.7.

Dat PHP 'm niet meer officieel support, betekend niet dat de distro's dat ook niet meer doen. Zeker in HA / Enterprise omgevingen geld: als het niet stuk is, ga 't dan niet repareren.

De meeste distro's (lees: de goeie) voeren namelijk gewoon de security fixes door met backports. Qua security ga je er niet op achteruit, alleen qua feature set. Maar als je HA / Enterprise wil, wil je automatisch al geen bleeding edge.

[Precision]

[...]als het niet stuk is, ga 't dan niet repareren.[...]

Maar wanneer is iets stuk? Als blijkt dat iets niet meer veilig is dan is het stuk maar komt 't pas boven water als iemand iets probeert die hij niet mag.

[Xesxen]

Als je gebruikt maakt van hashing om bijv. in te loggen, is dat niet zo handig als de gebruikers niet kunnen inloggen. Ik gebruik de hashing om samen met twee string, username en het password een hash te maken, welke ik daarna valideer met wat in de database staat. Als alles niet meer klopt...

[Tomdevries]

In geval van authenticatie zal je huidige systeem inderdaad falen. Echter, wanneer je met deze bug een nieuwe account registreer wordt je wachtwoord gehashed opgeslagen als de plain salt.

Wanneer bij het inloggen dezelfde crypt wordt gebruikt, die immers altijd dezelfde hash (de salt in dit geval) teruggeeft, is het dus mogelijk om met wat voor wachtwoord dan ook in te loggen.

[Reactie gewijzigd door Tomdevries op 24 juli 2024 07:25]

[ChaoZero]

Nee je hebt het goed.
Anderzijds (wanneer je even probeert, en kijkt of bij veranderende invoer dezelfde salts terugkomen!) geeft het wel een klein stukje van de beveiliging bloot.

Stel bijvoorbeeld dat ieder wachtwoord 'ge-salt' wordt met $password_ditiszout, dan zou ik john the ripper instrueren achter iedere try "_ditiszout" te plakken. Scheelt natuurlijk een boel tijd om te bruteforcen maar een sterk wachtwoord blijft een sterk wachtwoord!

[Phoib]

Gevalletje "oeps, verkeerde variabele teruggeven"

Nu is dit hier niet zo'n ramp als 5.2.7, md5 is al onveilig, en de salt voegt weinig tot niks toe.

[Booster]

Uh, die salt zorgt anders wel voor een flinke extra drempel voor het bruteforce kraken van wachtwoorden met meer dan 7-8 karakters. Dat is tegenwoordig een cruciale toevoeging.

[Phoib]

Enige keer dat een salt nuttig is is als je de hash in handen krijgt, en in de meeste gevallen heb je dan ook wel de salt erbij (SQL injectie).

Aangezien je de salt en het eindresultaat hebt, moet je alleen nog weten hoe de salt gebruikt wordt. Als je een custom site hebt kan je je eigen methode verzinnen, maar als je een forum gebruikt is de implementatie van de salt bekend.

Nu is het nog een kwestie van rainbowtables hashen met de salt en vergelijken. Die salts zijn meestal een paar karakters, dus md5 kan er in een keer, snel, doorheen.

Natuurlijk, het duurt langer om die gehashte rainbowtable te maken en te vergelijken, maar veiliger dan een gewoon gehasht password? Nee. Er blijft dezelfde kans op collisie, en je blijft in dezelfde orde van grote van oplossingen die je door moet lopen om te bruteforcen.

md5 met salt is niet substantieel veiliger dan md5 zonder salt.

[deadinspace]

Enige keer dat een salt nuttig is is als je de hash in handen krijgt, en in de meeste gevallen heb je dan ook wel de salt erbij

Natuurlijk heb je de salt er bij, die is onderdeel van de hash!
En natuurlijk heeft een salt alleen zin tegen het offline kraken van hashes, dat is waar salts voor bedoeld zijn.

Aangezien je de salt en het eindresultaat hebt, moet je alleen nog weten hoe de salt gebruikt wordt.

Het is gewoon gestandaardiseerd hoe een salt toegepast wordt, daar is niks geheims aan. Een salt voegt geen extra geheimzinnigheid toe. Een salt dient puur om rainbow tables nutteloos te maken.

Nu is het nog een kwestie van rainbowtables hashen met de salt en vergelijken.

Nee, dat heeft geen enkele zin. Elke hash heeft zijn eigen salt, dus je kunt geen rainbow tables maken voor een bepaalde salt. Het enige dat je kunt doen is rainbow tables maken voor alle salts, maar daarmee worden de rainbow tables onmogelijk groot. En nogmaals, dat (en niet meer) is precies het nut van een salt.

Bij MD5 is een salt van 8 6-bit tekens gebruikelijk, dat betekent dat de rainbow tables 2⁴⁸ = 281.474.976.710.656 maal zo groot moeten zijn. Dat is onhaalbaar, en dus heeft precomputation geen zin meer.

en je blijft in dezelfde orde van grote van oplossingen die je door moet lopen om te bruteforcen.

Ja, maar nogmaals: dat is niet waar een salt voor dient. Een salt is om precomputation (rainbow tables) onaantrekkelijk te maken waardoor een aanvaller moet bruteforcen ipv een rainbow table lookup te doen.

md5 met salt is niet substantieel veiliger dan md5 zonder salt.

Wel dus. Voor een redelijk specifieke aanval weliswaar (precomputed dictionary attacks aka rainbow tables), maar dat is een vrij relevante aanval als het op wachtwoordhashes aankomt.

[Reactie gewijzigd door deadinspace op 24 juli 2024 07:25]

[Booster]

Ik denk dat je een gedeelte van de werking van salt mist
http://en.wikipedia.org/wiki/Salt_%28cryptography%29

Uiteraard moet je nogsteeds ook wachtwoorden laten maken van een bepaalde sterkte voor het nut gaat hebben, maar die restricties zijn niet erg bijzonder.

[Phoib]

Ik denk dat je een gedeelte van de werking van salt mist
http://en.wikipedia.org/wiki/Salt_%28cryptography%29

Uiteraard moet je nogsteeds ook wachtwoorden laten maken van een bepaalde sterkte voor het nut gaat hebben, maar die restricties zijn niet erg bijzonder.

De sterkte van het wachtwoord wordt minder relevant als de hashmethode zelf onveilig blijkt. MD5 is niet veilig meer, er bestaan efficiente methodes om vanuit een hash een oplossing te achterhalen.

Zie ook http://www.win.tue.nl/hashclash/ HashClash voor de veiligheid van MD5.

[deadinspace]

De sterkte van het wachtwoord wordt minder relevant als de hashmethode zelf onveilig blijkt.

Dat klopt.

MD5 is niet veilig meer, er bestaan efficiente methodes om vanuit een hash een oplossing te achterhalen.

En dat klopt niet helemaal.

Er bestaan nog geen bijzonder efficiente methoden om vanuit een hash een oplossing te genereren (een zogenaamde preimage attack). De efficientste preimage attack tegen MD5 heeft een complexiteit van 2¹²³ (zie hier), wat significant hoger is dan de entropie van vrijwel alle wachtwoorden. Dat betekent dat brute force (al dan niet met een dictionary) nog steeds efficienter is.

Wel zijn er efficiente collision attacks gevonden (dat is waar jouw HashClash link over gaat), maar die genereren alleen twee inputs die naar dezelfde waarde hashen, en zijn dus nutteloos als je naar een specifieke hash toe moet werken. Het is met dergelijke collisions absoluut mogelijk om narigheid uit te halen (zie de Certificate aanval), maar op wachtwoordhashes heeft het geen invloed.

Begrijp me niet verkeerd; er zijn hele significante problemen met MD5, en die zullen alleen maar erger worden. Ik juich het gebruik van betere hashes (met name SHA-512) van harte toe, maar MD5 voor wachtwoordhashing is niet zo lek als jij doet voorkomen. En dat betekent dus dat een veiligheidsprobleem in PHP's MD5 implementatie relevant is.

[Verwijderd]

Als je vanuit een hash een oplossing kunt achterhalen, dan heb je zo'n beetje het beste compressie algorithme ter wereld bedacht. DVDtje overzetten? Gewoon hash kopiëren en later weer even omzetten naar data.

Er zijn collisions gevonden (dwz. verschillende payloads die dezelfde hash dragen), en er zijn verschillende exploits gevonden. Zo kun je een standaard payload hebben, met arbitraire extra data, die altijd dezelfde hash vormen. Daarmee kun je bepaalde executables manipuleren en daar bijvoorbeeld virussen in verstoppen, zonder dat programma's die hashes checken (zoals package managers op Linux) het door hebben (hoewel diezelfde package managers nu allemaal betere hashes, zoals SHA1, gebruiken).

Voor wachtwoorden is MD5 nog lang niet 'heel slecht', zeker omdat je hashes gewoon niet om kunt draaien. Door collisions is het wel wat gevaarlijker. En omdat je een MD5 sneller kunt berekenen dan bijv. een SHA1 hash, is MD5 ook zwakker (ivm brute force attacks, etc).

[deadinspace]

Als je vanuit een hash een oplossing kunt achterhalen, dan heb je zo'n beetje het beste compressie algorithme ter wereld bedacht. DVDtje overzetten? Gewoon hash kopiëren en later weer even omzetten naar data.

Nee hoor. Dat je een oplossing voor een hash kunt vinden wil niet zeggen dat dat ook de originele input is. Het kan een heel andere input zijn dit simpelweg tot dezelfde hash leidt.

Vergeet niet, er zijn oneindig veel inputs die tot eenzelfde hash leiden

[ACM]

Puur md5 is domweg zo snel te berekenen dat een salt het weinig minder interessant maakt om te brute forcen. Uiteraard moet je dan elk account los brute forcen, maar dan nog is het prima mogelijk als je bedenkt dat met de huidige generatie GPU's (mijn Radeon 6950 iig) je al makkelijk 1-2 miljard md5-hashes per seconde kunt uitproberen.

[hostname]

Maar als je nu per gebruiker een andere salt maakt dan moet er per gebruiker een nieuwe rainbowtable aangelegd worden, wat de tijd die benodigt is om de hash te kraken enorm vergroot.

[Phoib]

Niet erg veel groter, md5 is, zoals ACM al zegt, erg snel uit te rekenen, zeker als de salt minder dan 32 characters heeft, want dan kan md5 er in een keer doorheen.

Het zal zeker langer duren, maar niet substantieel langer. Het duurt niet opeens 10.000 keer zo lang, en het risico voor collisions blijft hetzelfde.

md5 is niet veilig meer, en een salt voegt daar weinig aan toe.

[deadinspace]

Nu is dit hier niet zo'n ramp als 5.2.7

Eh, niet zo'n ramp? De manier waarop de crypt() functie in 5.3.7 faalt zou ervoor kunnen zorgen (een en ander hangt van details af) dat aangemaakte gebruikers op een site met elk willekeurig wachtwoord kunnen inloggen.

md5 is al onveilig

Er zijn problemen met MD5, maar die zijn (nog) niet relevant voor het gebruik van MD5 als wachtwoordhash. Het is verstandig om naar andere hashing algoritmes te migreren, maar dat betekent niet dat MD5 per definitie onveilig is.

Overigens is MD5 nog altijd ordegroottes beter dan DES als wachtwoordhash.

en de salt voegt weinig tot niks toe.

Niks is minder waar. Bij een standaard salt-grootte (8 tekens) wordt een rainbow table voor een dictionary attack een factor 2⁴⁸ = 281.474.976.710.656 groter, wat een dergelijke aanval onpraktisch maakt.

[Reactie gewijzigd door deadinspace op 24 juli 2024 07:25]

[Verwijderd]

Dan vraag ik me toch af of ze bij het PHP-team geen regressietests of unit tests hebben. Zeker bij dit soort functies, die toch redelijk "belangrijk" zijn (dat wil zeggen, dat het vrij ernstig is als er een fout in voorkomt) wil je voorkomen dat er per ongeluk een fout in slipt. Als je gewoon een test suite hebt met unit tests voor alle functies (of alleen de belangrijkste functies) en die draait voor het maken van een release, dan komt zo'n situatie nooit voor.

[BRAINLESS01]

Er zijn wel geautomatiseerde tests en als je ze uitvoert falen ze. Probleem is dat ze niet gebruikt zijn

[Blue-eagle]

En dat is gewoon nalatig. Als je op zoveel miljoenen servers draait kan je geen updates uitbrengen zonder er 100% zeker van te zijn dat alles klopt. Het stond vroeger al zo bekend als een pruts taaltje. Dit soort nieuws doet ze geen eer aan.

[Jaccoh]

offtopic:
Die onzin heb ik overigens nog nooit gehoord . Maar nalatig is het zeker wel als het waar is dat de tests er zijn maar niet uitgevoerd.

[YopY]

Als ze niet gebruikt worden zit er een zwakke schakel in het releaseproces - dwz dat mensen het (blijkbaar) handmatig moeten doen. Releases moet je via de CI server doen.

...als je die hebt natuurlijk.

[hostname]

Ze hebben wel een vrij goede en complete testsuite, maar deze geeft gemiddeld zo'n 200 fouten. Dat maakt zo'n testsuite meteen vrij nutteloos aangezien je het dan niet door hebt als er een extra test faalt.

Er wordt nu wel geroepen dat het handig is om die testsuite te fixen, maar dat vergt uiteraard tijd en het lijkt erop dat de PHP developers die tijd liever aan iets anders besteden.

[Reactie gewijzigd door hostname op 24 juli 2024 07:25]

[Niemand_Anders]

Dus dan haal je de testen welke foutmeldingen geven UIT de suite zodat je WEL weet wanneer een correcte test fout gaat. En dan kun je ook rustig een voor een de 200 testen welke fout meldingen geven repareren.

Een test suite welke standaard foutmeldingen geeft is volledig nutteloos. Test dan gewoon niet. Is half goed doen is vele malen erger dan iets niet doen!

[intel_478]

Dit is nou een van de redenen dat ik bepaald geen fan ben van php. Die mentaliteit wat testen betreft is niet aan mij besteed.

[RubenBentein]

Het kan ook zijn dat ze dit scenario gewoon vergeten testen zijn in hun testcase... Het is ook niet dat de hele functie niet meer werkt. Enkel wanneer er gecrypt wordt met MD5 en een eigen salt.
Om hierdoor direct te gaan zeggen dat PHP een mentaliteit heeft van niks te testen is wat grof. Alsof elke developer hier nog nooit een incomplete test heeft geschreven...

[Antipater]

Alleen in dit geval was er wel degelijk een unittest voor die faalde. De bug was ook nog eens geintroduceerd door met werkende code te rommelen.

Dat je zomaar code released waar het halve internet op draait, wetende dat er allerlei unittests falen, je niet de moeite neemt ze te bekijken en in security code gaat zitten harken...Ik zou dit niet als best practice willen omschrijven.

[daft_dutch]

Ik ben een grote fan van PHP. De documentatie is uitstekend, functionaliteit,simpliciteit dito
En over testen 200 fouten zijn bekende risico's dus altijd beter dan onbekende risico's.

Mijn automatische test facilitator is geschreven in PHP en de taal bij uitstek voor dit doel. Het zorgt er voor dat we automatisch na een voltooide build automatisch de boel installeren/configureren (snapshot) test omgeving opzetten. (snapshot) en testen. Of de applicatie server nu Windows,Linux of AIX is en de database nu lokaal/remote oracle of MSSQL is. En of de boel nu ESX,VMworkstation of echt is. (snapshot faalt wel eens)
Elke blocking installatie/configuratie bug is een major feature request voor de php code.
En je met php in no time die feature er in kan hacken.

Voor deze toepassing zijn Leesbaarheid,flexibiliteit/aanpasbaarheid heel belangrijk. performance NULL en veiligheid vergelijkbaar met 0

Maar als 24/7 stabiliteit, top performance en data integriteit (zonder dat geen veiligheid) de eisen van jou software zijn. Is PHP niet de software die je zoekt. Dat is nog altijd c en/of c++

[Reactie gewijzigd door daft_dutch op 24 juli 2024 07:25]

[YopY]

Hoe kunnen ze tijd aan iets anders besteden als hun software gewoon stuk is? wat een baggermentaliteit.

[Sfynx]

Er wordt nu wel geroepen dat het handig is om die testsuite te fixen, maar dat vergt uiteraard tijd en het lijkt erop dat de PHP developers die tijd liever aan iets anders besteden.

Waarvoor hebben ze die testsuite dan eigenlijk gemaakt?

[daft_dutch]

Dan vraag ik me toch af of ze bij het PHP-team geen regressietests of unit tests hebben. Zeker bij dit soort functies, die toch redelijk "belangrijk" zijn (dat wil zeggen, dat het vrij ernstig is als er een fout in voorkomt) wil je voorkomen dat er per ongeluk een fout in slipt. Als je gewoon een test suite hebt met unit tests voor alle functies (of alleen de belangrijkste functies) en die draait voor het maken van een release, dan komt zo'n situatie nooit voor.

Als jij een keer php Zelf gecompileerd had wist je het antwoord. Er zijn iets van veertien duizend of zo

[WhiteDog]

Denk dat het allemaal nog wel meevalt. Veel servers zitten nog gewoon op 5.2.x en zelfs al ben je over naar 5.3.x dan ja je ook niet snel een productiemachine upgraden naar de allerlaatste versie zonder goeie reden.

Bovendien moet je ook nog is een bepaalde functie op een bepaalde manier gaan gebruiken. De waarschuwing is er vooral omdat je met deze bug je achterliggende database gaat vervuilen met verkeerde data en/of je ineens fouten krijgt bij verificatie van strings. Je kan hier ook niet meteen een workaround voor verzinnen zonder je code en database aan te passen.

[hostname]

Ik denk dat 6 securityfixes opzich wel een goede reden zijn om je productieserver te updaten naar de nieuwste versie.

Verder is het een kwalijke zaak dat veel servers nog op 5.2.x draaien, support daarvoor is al meer dan een jaar geleden gestopt en het moet voor developers inmiddels wel mogelijk gaan worden om de nieuwe features uit 5.3 te gebruiken. Het is jammer dat door dit soort fouten het upgraden van PHP niet zo heel vanzelfsprekend is als het zou moeten zijn en er vaak (terecht) extra voorzichtig wordt gedaan om te voorkomen dat er iets stuk gaat.

[deadinspace]

Verder is het een kwalijke zaak dat veel servers nog op 5.2.x draaien, support daarvoor is al meer dan een jaar geleden gestopt

Dat hangt maar net van je platform af. Er zijn namelijk vendors die nog wel degelijk security support leveren op PHP 5.2.x.

Zo bevat Debian 5.0 (Lenny, oldstable) PHP 5.2.6 en levert daar ook nog gewoon security support op tot april 2012. De PHP in Lenny heeft dan ook al 13 updates ondergaan.

[Verwijderd]

Ironisch genoeg is de fout veroorzaakt door Rasmus Lerdorf zelf. Toch maar eens die unit tests runnen voordat je je applicatie uitbrengt...

[Little Penguin]

Daar heb je alleen wat aan als je ook de bewuste functie zelf test. In theorie zou je voor alle functies een unit-test moeten hebben, maar zodra zoiets niet het geval is het je dus niet aan een unit-test.

Ik mag aannemen dat men voor deze functie nu wel een -goede- test maakt...

(waarbij we er voor het gemak van uit gaan dat men al unit-testen gebruikt...)

[Intrepidity]

Er waren al lang unit tests voor deze functionaliteit. Ze zijn alleen niet vlak voor release nog eens gedraaid, wat gewoon zeer slordig is.

[mocean]

Je zou toch zeggen, dat zo'n fout bij een unit-test wel gelijk naar boven zou komen! Ongelooflijk dat zo'n fout helemaal doorkomt tot de stable release.

Ben wel benieuwd hoe lang deze bug al in de code zit van 5.3.7, kan iemand dat makkelijk zien uit mbv source control?

[koku]

Volgens mij faalde de betreffende Unit Test ook, dat is het vreemde eraan. Dit staat er namelijk in het bug report:

Confirming, some very recent update broke it - right now unit tests fail on SVN. I
wonder if nobody run it before release?

Waarschijnlijk gewoon niet opgevallen dus. Wellicht omdat er standaard een hoop tests falen/skippen, waardoor het niet duidelijk is?