PHP haalt versie 5.2.7 uit roulatie vanwege beveiligingslek

De ontwikkelaars van PHP hebben voor zover bekend voor het eerst in de geschiedenis van de populaire scripttaal, een versie teruggetrokken nadat deze al officieel was uitgebracht. Versie 5.2.7 blijkt een ernstige bug te bevatten.

Versie 5.2.7 werd op 4 december vrijgegeven, zeven maanden na zijn voorganger. Daags na de release werd echter een beveiligingslek ontdekt, wat de ontwikkelaars heeft bewogen om maandag versie 5.2.8 te introduceren. Veel woorden maken de ontwikkelaars niet vuil aan het ontdekte lek: "Door een beveiligingslek dat in PHP 5.2.7 is ontdekt, is deze versie teruggetrokken. De bug heeft betrekking op systemen waar magic_quotes_gpc is ingeschakeld, omdat het uitgeschakeld blijft."

Als magic_quotes_gpc is uitgeschakeld, wordt een systeem vatbaar voor sql-injectie tenzij een programmeur in zijn code aanvullende beveiligingsmaatregelen treft. De magic_quotes-functie voorziet variabelen automatisch van escape-tekens, zodat onder andere kan worden voorkomen dat aanvallers invoervelden van een webpagina gebruiken om code uit te voeren. Magic_quotes_gpc zorgt dat deze functionaliteit wordt toegepast op de get-, post- en cookie-variabelen in http-requests. Veel programmeurs vertrouwen op deze functionaliteit omdat deze in PHP standaard is ingeschakeld.

De ontwikkelaars achter PHP nemen de implicaties van het ontdekte lek dermate serieus dat ze zondag hebben besloten de gehele versie uit roulatie te nemen en maandag PHP 5.2.8 vrij te geven. Normaliter zit er een aantal maanden tussen twee versies, waarbij eventuele bugs met updates worden verholpen. De laatste keer dat twee versies zo kort op elkaar volgden, was in augustus 2006. PHP 5.1.6 volgde toen al na twee weken versie 5.1.5 op.

Reacties (56)

Klopt, magic_quotes staat niet standaard aan. Magic_quotes verdwijnt ook vanaf PHP6. Daarnaast kun je als je magic_quotes aan hebt staan, dingen die je niet in een database wil hebben weer stripslashen (stel je wil juist iets op het scherm zetten) en iedere keer dat je, je applicatie op een andere server zet, mag je gaan controleren of magic_quotes aan of niet aan staan. En dan moet je maar hopen dat jij of je klant daar uberhaupt iets over te zeggen hebt.

[Reactie gewijzigd door flijten op 9 december 2008 11:03]

Ik vind magic_quotes niks anders dan irritant. Het maakt de programmeur lui en je code is niet portable naar servers waar deze debiele optie uitstaat.
Hoe vaak je wel niet mailtjes of pagina's ziet waarbij er dingen als "don\\\\\\'t" staan...

Ik heb een jaar lang .NET geprogrammeerd met MSSQL. Daar had .Net ook een beveiligingsframework tegen SQL injectie. Als er maar iets leek op SQL injectie werd de request gewoon afgebroken met een exceptie. Leuk en aardig dat het me beveiligt, maar ik had alles al afgevangen in de code, en die quote was nou juist de bedoeling in dat tekstveld. Voordeel bij ASP.Net is dat je per pagina dit soort beveiligingen uit kunt zetten.

Wat kan ik zeggen...
http://thedailywtf.com/Articles/Injection_Rejection.aspx

Ehm, vreemd .Net heeft gewoon paramaterized queries waarbij het 'onmogelijk ' is om SQL injectie te doen. Je maakt gewoon een object aan en doet Paramters.Add(string) en whoppa een nieuwe parameter die netjes door het .net framework ge-escaped wordt zodat er uberhaupt geen injectie kan ontstaan.

Welk beveiligings framework heb je gebruikt? Want ik vind dit maar vreemd

Hij doelt op het invoeren van speciale karakters in invoervelden op je forms. Bijvoorbeeld '\' en '<'. Als je dat soort karakters wilt kunnen invoeren in een tekstveld, zul je een van de validatiemethoden voor die pagina uit moeten zetten. Anders gooit .NET inderdaad een exceptie vanwege mogelijke injection.

Zie deze link voor meer informatie.

[Reactie gewijzigd door Cloud op 9 december 2008 12:02]

Niet portable? Met get_magic_quotes_gpc() kijken of de functie is uitgeschakeld en zo nee alle slashes weer wegjoppen.

Deze constructie zet je dan in een losse file en include je in elk PHP project.

[Reactie gewijzigd door TheBorg op 9 december 2008 11:44]

Het bestaan van deze functie zet aan tot lui programmeren. Iemand die gebruikmaakt van deze debiele functionaliteit gaat dus echt niet inkomende data escapen. Als je dat soort code vervolgens gaat uitvoeren op een server waar het uitstaat (of aanstaat maar niet werkt zoals in 5.2.7), heb je een gigantisch beveiligingslek in je code staan. Nee dankje.
De door jou genoemde functie moet je ook nog goed mee oppassen wat je doet. Als je bij elke binnenkomende request vantevoren al de slashes er weer uitsloopt zoals je zelf zegt, is er geen probleem. Als je aan de hand van de waarde van die functie besluit om helemaal niks aan input validatie te doen omdat PHP dat al voor je doet, heb je met 5.2.7 alsnog een lek in je code zitten.

Daarom is 5.2.7 ook teruggetrokken he

Er is niks mis met filtering op deze manier. Je kan je nou eenmaal lastig wapenen tegen bugs in de onderliggende taal, net zo min als dat je een beveiliging tegen een lek in Apache kan maken die 100% foolproof is. Lekken in onderliggende software zijn altijd buiten je macht als programmeur.

Het probleem met magic_quotes is dat PHP alvast voor mij bepaalt dat ik het in een MySQL database ga zetten. Als ik het in een email of een tekstfile wil opslaan heb ik allerlei onnodige slashes in mn output. Een dergelijk filter op alle input toepassen is slecht, iets wat de PHP ontwikkelaars ook hebben ingezien. Het is niet voor niks dat deze functie uit PHP wordt gesloopt bij PHP 6, evenals safe_mode.
Er zijn inmiddels wel betere filterfuncties voor PHP beschikbaar: http://nl.php.net/manual/en/intro.filter.php

iedere keer dat je, je applicatie op een andere server zet, mag je gaan controleren of magic_quotes aan of niet aan staan. En dan moet je maar hopen dat jij of je klant daar uberhaupt iets over te zeggen hebt.

Of je schrijft gewoon goede degelijke code die in je abstraction layers checkt of magic_quotes aan staat en ze zo ja ongedaan maakt. Serverafhankelijke code is baaaad mmmkay.

Tuurlijk kan dat, maar je kan ook gewoon overal waar het wel hoort htmlspecialchars en dergelijke toepassen. Dan doe je precies wat je wilt en wanneer je het wilt en ben je ook nog eens server onafhankelijk.

Serverafhankelijke code is inderdaad baaaad. Okay


@Cloud
Magic_quotes is inderdaad geen probleem voor een goede programmeur. Die zet het gewoon uit

[edit: zorgt dat het uit blijft staan]

[Reactie gewijzigd door flijten op 9 december 2008 11:55]

Het escapen is iets aan de invoer kant terwijl htmlspecialchars iets is aan de uitvoerkant. Hiermee los je dus niks op wat er tussen ligt.

Daarnaast is het extra grappig dat je in het begin zegt dat serverafhankelijke code 'bad' is, terwijl je in de laatste zin aangeeft dat een goede programmeur een setting verplicht op off zet en dus wel server afhankelijk zou moeten werken....

flijten bedoelt dat je magic quotes zelf kan uitzetten, ook al staat het aan in de serverinstellingen. Gewoon .htaccess aanpassen, klaar!

Geen magic quotes-miserie meer, en dit werkt op elke server.

En als je geen .htaccess toegang hebt kan het nog helemaal vanuit PHP met een iets omslachtige en meer geheugen gebruikende manier zoals hier:
http://nl3.php.net/manual...magicquotes.disabling.php (zie Example #2).

En als je geen .htaccess toegang hebt ...

word het misschien eens tijd om op zoek te gaan naar een andere hoster

Dat sowieso ja
Maar soms wil je misschien niet uitgaan van een .htaccess die een klant zelf kan aanpassen. En dan is het misschien handig om dit te doen ipv die('magic quotes gpc staat aan'); o.i.d.

Het uitzetten van magic quotes is het aanpassen van een server instelling. Dat je het moet doen betekend dus dat je applicatie afhankelijk is van serverinstellingen.

Zoals curry al aangeeft kun je gewoon get_magic_quotes_gpc() gebruiken in je code om je applicatie onafhankelijk te maken van server instellingen.

Maar wat nou als het CMS wat je gebruikt niet inzichtelijk maakt of het afhankelijk is van magic_quotes? Ik maak bijvoorbeeld veel gebruik van Joomla en heb meerdere sites gehost bij een externe hostingpartij. Aangezien het om een shared server gaat heb ik geen toegang tot de php-settings. Nu maak ik me niet zoveel zorgen om joomla zelf, dat zit doorgaans wel goed in elkaar. De extenties die ik heb geinstalleerd echt worden een onnodige liability. Ik weet niet hoe die omgaan met variabelen. Gelukkig waarschuwt joomla mij en weet ik dus dat ik de site eigenlijk niet in productie kan gebruiken.

PHP magic_quotes_gpc setting is `OFF` instead of `ON`

Vaak kun je het ook in .htaccess uitzetten, maar je moet het blijven controleren in je eigen code.

Jammer dat men deze ellende ooit in PHP heeft gezet, nu komt PHP er slechts met pijn en moeite weer vanaf. De "bug" met 5.2.7 is daar ook een direct gevolg van.

Vertel dat de tien (honderd?)-duizenden hobbybob's die met PHP knoeien. Die hebben nog nooit van een abstraction layer gehoord.

Magic_quotes is geen probleem voor een goede programmeur, maar van de mensen die PHP gebruiken zonder erbij na te denken.

"...maar van de mensen die PHP gebruiken zonder erbij na te denken."

Mensen die PHP gebruiken zonder erbij na te denken bestaan niet. Iemand die niet weet wat het "escape"-en van "speciale karakters" inhoud en wat de gevolgen daarvan zijn, is niet bewust op zoek naar een oplossing hiervoor. Alles moet dus komen met ervaring, die duizenden hobbybob's kun je dus niets kwalijk nemen, maar alleen maar adviseren.

Verder kan het magic_quotes probleem goed opgelost worden door een paar regels code te schrijven in een bestand dat alle andere php bestanden included. Je zou daarbij dus de code van hierboven kunnen gebruiken of er zelf één maken (is te doen in minder dan 15 regels code, afhankelijk van hoe je de code opmaakt natuurlijk). Verder zou ik hierbij geen regular expressions gebruiken omdat deze geloof ik in PHP6 bij de PECL extensies komt.

http://www.php.net/~deric...es.html#move-ereg-to-pecl

Edit: @Cloud
Misschien interperteerde ik "zonder erbij na te denken" als te onbeschoft, dus vandaar Het is maar net hoe je het opleest.

De magic-quotes is een probleem voor iedereen die geen diepe kennis van programmeren heeft. Doordat het al voor jou gedaan wordt, is de neiging groot om het maar te laten.

[Reactie gewijzigd door Memori op 9 december 2008 17:57]

Mensen die PHP gebruiken zonder erbij na te denken bestaan niet. Iemand die niet weet wat het "escape"-en van "speciale karakters" inhoud en wat de gevolgen daarvan zijn, is niet bewust op zoek naar een oplossing hiervoor. Alles moet dus komen met ervaring, die duizenden hobbybob's kun je dus niets kwalijk nemen, maar alleen maar adviseren.

Volgens mij begrijp je mij verkeerd, of ik begrijp jouw reactie verkeerd.

Maar er bestaan wel degelijk mensen die lekker aankloten met PHP zonder erbij na te denken. En of ze nu wel of niet kennis van escaping en specialchars hebben, en of ze nu wel of niet een oplossing zoeken ervoor, escaping is en blijft een probleem voor ze. En daarmee magic_quotes ook.

Nu kun je stellen, ach die hobby bob's maken toch geen kritieke sites waarbij het niet uitmaakt als ze zo kwetsbaar zijn als een baby in een brandend huis. Misschien is dat ook wel zo, maar dat neemt niet weg dat ze er wel degelijk last van kunnen hebben.

Ik neem ze dus ook niets kwalijk, maar dat probeerde ik ook nooit te doen. Ik stel alleen maar dat magic_quotes een probleem voor ze is en niet voor een doorgewinterde PHP programmeur.

De enige die wat te verwijten valt is diegene die magic_quotes in PHP bedacht heeft.

[Reactie gewijzigd door Cloud op 9 december 2008 15:19]

geen probleem, nou... dat je er steeds rekening mee moet houden dat een webserver iets kan doen met de userinput waar je soms (in shared hosting omgevingen) niet eens zeggenschap over hebt kan je toch wel ronduit irritant noemen.
Je KAN er wel rekening mee houden in je code, maar dat zou eigenlijk helemaal niet nodig moeten zijn.

[code]
function fix_magic_crap()
{
// Fuck off with your crap magic quotes:
if (get_magic_quotes_gpc() == 0)
return;

// Only do it once:
if (defined('CRAPFIXED'))
return;

define('CRAPFIXED',1);

// It's set, remove it from all variables:
fix_magic_crap_array($_GET);
fix_magic_crap_array($_POST);
fix_magic_crap_array($_COOKIE);
fix_magic_crap_array($_REQUEST);
}


function fix_magic_crap_array(&$array)
{
foreach ($array as &$val) {
if (is_array($val))
fix_magic_crap_array($val);
else
$val = stripslashes($val);
}
}


fix_magic_crap();
[/code]

Voor de mensen die het graag altijd uit willen hebben.

Je vergeet magic_quotes_runtime nog uit te zetten.

f je schrijft gewoon goede degelijke code die in je abstraction layers checkt of magic_quotes aan staat en ze zo ja ongedaan maakt.
En die check retourneerde wel true, dus strip je mogelijk dingen eruit die er niet via magic_quotes_gpc ingezet zijn. Dus juist degelijke code welke ongeacht de server settings moet kunnen werken heeft juist een probleem.

[Reactie gewijzigd door Voutloos op 9 december 2008 11:49]

Inderdaad, ik heb nooit vertrouwen genomen in magic_quotes en een goede programmeur zal dat ook nooit gedaan hebben, er bestaan tientallen papers die met goede argumenten het gebruik van magic_quotes sterk afraden.

De magic_quotes functies binnen PHP zullen in PHP 5.3 sowieso standaard uit staan (indien niet verwijderd); de mogelijkheden zijn verouderd en zullen binnenkort wellicht vervangen worden door trainted variables om de beveiliging beter te waarborgen; op meerdere en efficiëntere niveau's. In verschillende PHP 5.3 releases geeft Magic Quotes nu zelfs al een D_DEPRECATED error.

Magic Quotes staat altijd uit sinds PHP5. Het wordt in 5.3 idd met een deprecated error gegeven en in PHP6 er helemaal uitgehaald.

Zoals je kunt lezen is het probleem hier niet dat magic_quotes uit staat, maar dat het niet werkt wanneer het ingeschakeld wordt! Dat is uiteraard wel een groot risico, als je applicatie er op rekent.

Gelukkig gaat deze zooi er in PHP6 uit. Dan zal het nog wel een tijd duren voordat iedereen over is en we van het magic quotes-gezeik af zijn.

Goede PHP-programmeurs zullen toch al geen gebruik maken van de automatische escape functies en het lekker zelf doen.
Ben alleen benieuwd hoeveel applicaties straks onveilig zullen zijn... maarja, dat is de verantwoordelijkheid van de programmeur.... Maar voor nu is het goed dat ze de versie hebben teruggetrokken.

Terwijl het tegenwoordig de andere richting uit gaat in moderne talen: daar zeg je wat je wil en niet meer hoe je iets wil. Zo ook in ASP.NET met parameterisatie. Misschien is de magic quotes functionaliteit gewoon ruk en niet zozeer het idee
Magic quotes waren gewoon ruk !

[Reactie gewijzigd door ? ? op 9 december 2008 12:48]

Die magic-quotes mogen er van mij nu al uit, iedereen die daarop vertrouwd is niet goed bezig. User-input hoor je zelf de controleren, te valideren of onschadelijk te maken en daarvoor heb je geen optie nodig die alles maar escaped terwijl dat soms niet nodig is. Zeker nu je bij PDO prepared statements kunt gebruiken heb je al geen addslashes, mysql_real_escape_string e.d. nodig.

Beveiliging is belangrijk maar dan moet je het wel goed doen!

[Reactie gewijzigd door IvoVB op 9 december 2008 12:22]

Bij het compilen van PHP komt er soort van kleine testsuite mee ('make test') om het een en ander te controleren. (Waaronder bv oude bugs)

Aangezien er altijd een hoop gedoe is geweest met de magicquotes, vind ik het raar dat deze in deze hier niet getest zou worden.

Het probleem met het testen van magic quotes is dat ze werken via de input variablen, met name GET, POST en COOKIE (en in sommige gevallen ook SERVER). Bij de test-suites is er geen user input, omdat ze via de command line uitgevoerd worden. Natuurlijk kan het wel op enige mate via de $argv variable getest worden, maar ook dat is redelijk gelimiteerd en ik weet niet zeker of de test-suites daarop aangepast zijn.

Tijd voor een uitbreiding op de testsuite dus.

Uiteindelijk is zou het "standard procedure" moeten zijn om al je onbekende tekstvakken te filteren met een functie die kijkt of je magic quotes aanstaan, en die in het geval dat het niet aanstaat, de functie addslashes uitvoert

Sorry, juist niet!!

De manier van escapen is helemaal afhankelijk van de context. In een query escape je anders dan voor het direct weergeven van een stuk html. En binnen html is er nog eens een verschil tussen gewoon 'tekst' of een property van een formulier veld. Bij het wegscrijven naar een bestand wil je helemaal geen escaping!

Probleem is met veel shared hosting waar dus magic quotes gebruikt wordt, je niet zelf mysql_real_escape_string of addslashes kan gebruiken, omdat als je die toevoegt aan je script 2x ge-escaped wordt, en men het dus achterwege laat. Wanneer dan later de magic quotes eruit vliegt, zit iedereen met onveilige zooi, en ben je een eindje bezig om alle query's aan te passen.

Juist daarom zijn dingen als .htaccess bedacht, waarmee je het gewoon zelf uit kan zetten. Mocht dat niet kunnen, heb je altijd nog stripslashes(). De "ik kan ook PHP" niveau mensen zullen altijd een risico vormen, net als mensen die denken dat ze kunnen programmeren in enige andere taal. User stupidity is niet op te lossen door een programmeur, programmer stupidity niet door een taal.

De "ik kan ook PHP" mensen zullen dat risico maar gewoon moeten accepteren vind ik, een taal moet daar geen onhandige "oplossingen" voor proberen te maken.
Dus MQ eruit...

Alhoewel ik het opzich zou aanmoedigen, zou ik er absoluut niet blij mee zijn. Als jij je site op een shared hosting bak zet, waar toevallig een of andere prutser uit de eerder genoemde "ik kan het ook" categorie zijn lekke site heeft staan, ben jij ook de pineut. Jouw code mag dan tegen SQL injection bestand zijn, die van hem niet. Dat kan behoorlijk negatieve gevolgen hebben voor jouw website, helemaal wanneer de webhoster niet alles volledig heeft dichtgetimmerd.

Magic Quotes is niet geweldig, maar het beschermt wel tegen een aantal problemen die veroorzaakt worden door mensen die eigenlijk ver weg moeten blijven van programmeren.

Bij een fatsoenlijke hoster heb je dat probleem niet, of je neemt een dedicated server...

En buiten dat, het is eigenlijk wel mooi als die optie eruit gaat, dan gaan er ook weer wat prutsers weg en dat levert weer meer vraag op naar GOEDE PHPers...

[Reactie gewijzigd door IvoVB op 10 december 2008 16:28]

Afaik is magic_quotes_gpc al een tijdje niet meer standaard ingeschakeld om het gebruik ervan te ontmoedigen...

Wanneer gaat PHP nou eens een keer binaries maken voor 64 bit (voor windows)?

Ik zie ook geen 64 bit binaries voor Fedora 9 of 10, dus waarom zouden ze. Ik zie überhaupt geen binaries voor Linux... die moet je allemaal bij de distributies zelf weghalen... Je hebt de sources, dus ga je gang...

Vertel, waar baseer je dat op?
Ik gebruik al jaren geen magic_quotes meer, puur omdat ik liever zelf wil bepalen wat ik met m'n input doe. Op mij heeft het dus geen effect (daarnaast update ik de servers pas nadat een update stabiel/veilig genoeg is gebleken).

Python is als webscripting taal absoluut onbruikbaar bij grote projecten, omdat je simpelweg VEEL meer code nodig hebt voor hetzelfde resultaat. Geef mij maar PHP, er draait niet voor niets meer dan de helft van alle sites op PHP...

Dan een lesje kwaliteitsmanagement: kwaliteit laat zich niet meten in kwantiteit. De hoeveelheid code staat dus absoluut niet garant voor een zekere kwaliteit. Als je kijkt naar het prijskaartje dan zul je zien dat ze naar het aantal besteedde uren kijken: ofwel worden die doorberekend ofwel hebben ze een fixed price waarbij je dan winst hebt als je minder uren hebt besteed en verlies als je er teveel aan hebt besteedt. Een complexe taal die weinig regels code oplevert maar waar je wel ontzettend veel tijd aan kwijt bent door de complexiteit kan daardoor veel duurder en daarmee ongeschikter zijn dan een simpele taal die gewoon veel regels code heeft. Dat soort zaken zullen eerder bepalen of een taal wel/niet geschikt is voor een bepaald project, uiteraard zijn er andere belangrijkere eisen die bepalen of het wel/niet geschikt is.

Dat een heleboel op PHP en MySQL draait komt doordat het toentertijd enorm gehyped is en iedereen er bovenop sprong. Andere talen waren er toen ook al maar die zijn lang niet zo bekend geworden. Dat geldt ook voor databases zoals een PostgreSQL. Ook hier geldt dat de hoeveelheid weer totaal niets zegt over kwaliteit en dingen die er juist wel erg toe doen zoals de reden waarom men PHP gebruikt. Bovendien zijn heel erg veel sites eerder een mix van diverse talen en dat is niet voor niets !

Wat een grapjas. Python niet geschikt voor webdev? Je weet duidelijk niet waarover je praat. Python heeft 1 van de mooiste webdev frameworks op aarde: django. In no-time heb je een web applicatie gemaakt met admin.

Laat me even denken: niet voor niets gebruiken giganten als google (youtube, google code, en een HELEBOEL andere webapps), nasa en nog tientallen andere python.

Het feit dat DrWolf ongebaseerd loopt te trollen zegt nog niet dat je perse terug moet gaan flamen. Er is niks mis met Python en voldoet prima voor zowat alles waar je een scripting taal voor zou gebruiken. wat jij zegt is net zoiets als "C is beter dan Java, want je hebt bij Java meer code nodig voor hetzelfde". PHP en Python (en anderen, zoals Perl of Ruby) zijn allebei prima talen. Gebruik gewoon wat je het prettigst vind en laat aub de flamewar over aan de nieuwsgroepen...

Python is als webscripting taal absoluut onbruikbaar bij grote projecten, omdat je simpelweg VEEL meer code nodig hebt voor hetzelfde resultaat.

Heb je daar ook een bron voor? Mijn ervaring met Python/Django is nl. heel anders. Hoewel er voor PHP natuurlijk ook frameworks bestaan.

Geef mij maar PHP, er draait niet voor niets meer dan de helft van alle sites op PHP...

VB6 werd ook veel gebruikt Het is meer een kip-en-ei-probleem, PHP hosts zijn er in overvloed dus de meeste websites gebruiken het. Daarom is er voor hosters minder reden om andere talen te ondersteunen. Ik ben niet anti-PHP, gebruik het regelmatig en kan er prima mee overweg, maar het zit technisch gezien gewoon niet altijd even goed in elkaar in vergelijking met Python ofzo

[Reactie gewijzigd door JanDM op 9 december 2008 12:03]

Goede argumentatie. Omdat PHP developers een bug kritiek genoeg vinden om een versie niet te releasen, is het een bagger taal? Je wil zeggen dat Python de heilige graal is, geen bugs bevat en security leaks onmogelijk maakt?

Zie titel: het gaat dus om een kritieke security bug die NA een release is gevonden en niet er vlak voor! Voor de PHP devs in ieder geval kritiek genoeg om 5.2.7 offline te halen en te vervangen door 5.2.8 die de fix voor de bug bevat (plus de changes van 5.2.7). Versie 5.2.8 moet je dan ook zien als de vervanger voor 5.2.7 en niet als opvolger: je hebt dus 5.2.6 -> 5.2.8. Squirrelmail heeft ook zo'n sprong moeten maken omdat malware lui met een versienummer aan de haal gingen.

@hieronder: ja dat stel je wel degelijk, lees je eerste zin nog maar eens heel goed en naugezet na. Met name het stukje "een versie niet te releasen" doet vermoeden dat je doelt op een niet-gereleaste versie. Je hebt het dus niet over het cancelen van een release maar over een versie die niet is uitgebracht. Dat is dus onjuist omdat de versie wel is uitgebracht. Als je op een andere release doelt die daadwerkelijk niet vrij is gegeven vanwege een security bug is het ook handig dat je dat erbij zet. Ik ben alleen bang dat die niet bestaat omdat er meestal gewoon sprake is van een showstopper en dan komt de release pas wanneer deze is opgelost; de releasedate wordt dus opgeschort en niet gecanceled waarna men bij de volgende release met een nieuw versienummer verder gaat. Het gaat dus niet om het wel of niet van dingen snappen maar om het correct verwoorden. Dat laatste doe je niet en was voor mij de reden om je subtiel naar de titel te verwijzen in de hoop dat je het verschil met jouw stukje zou zien. Ijdele hoop gezien je reactie.

[Reactie gewijzigd door ppl op 9 december 2008 17:32]

Zeg ik ergens in mijn reactie dat ik het cancellen van 5.2.7 niet snap dan? Ik reageer enkel op de trollerige post van DrWolffenstein, waarin hij claimt dat PHP kut is en Python de heilige graal is. Overigens is deze drWolf zo gefrustreerd door PHP dat hij bij elke Meuktracker melding wel even moet klagen.
Met andere woorden: je kan wel tegen me zeggen dat ik moet lezen, maar daar heb ik weinig moeite mee. De volledige verhandeling van het hoe en wat over het terugtrekken van een release snapte ik na het lezen van het bericht al.

Edit:
Ik beschouw terug terugtrekken binnen een dag toch echt als cancellen van een release.

[Reactie gewijzigd door MueR op 9 december 2008 15:49]

Wat een onzin zeg. Hoezo zwalken ze hoe langer hoe meer? Dat jij overstapt naar Python is prima, maar dit soort losse beweringen zonder enkele vorm van argumentatie leveren niet veel bijdrage aan een goede discussie.