Software-update: phpBB 3.2

Versie 3.2 van phpBB is uitgebracht. Met dit programma is het mogelijk om een webforum te maken. PhpBB wordt onder de gpl-licentie beschikbaar gesteld en maakt gebruik van php en een databaseprogramma om berichten op te slaan. Naast MySQL worden ook PostgreSQL, Oracle Database, Microsoft SQL Server en SQLite als databasesoftware ondersteund. Versie 3.2 bevat onder meer ondersteuning voor php 7, recaptcha 2.0 en Symfony 2.8. Verder is het updateproces verbeterd, wordt er meer informatie getoond in geciteerde tekst en kunnen er meer emoji's worden gebruikt.

phpBB 3.2 Rhea Feature Release Published

Today is a big day for the entire phpBB community and we hope that you're as excited as we are! With the help of over one hundred volunteers, we have improved and extended phpBB to provide the new and improved phpBB 3.2 Rhea.

The new phpBB 3.2 Rhea builds upon 3.1 Ascraeus, upgrading the experience for users, administrators, and developers. The new BBCode parser adds support for all the emojis you've been using on mobile devices, the new font awesome integration adds retina quality icons to prosilver, and the quoting feature has been enhanced. Together with Symfony 2.8, an improved integration of the twig template engine, and full support for both PHP 7.0 & 7.1, we have increased extensibility of phpBB 3.2 while reducing development time.

Board admins will apprecite the new installer, which enables easier updating using the browser or a command-line interface, as well as the newly added reCAPTCHA 2.0 to thwart would-be spammers at the gate.

Check out further highlights of the new version on our Rhea Launch Page or a more detailed breakdown on our Features Page. As always, phpBB 3.2 Rhea and update packages for previous versions are available in the downloads section.

The phpBB community has been working hard to get this release prepared and work on phpBB 3.3 Proteus is already underway! In order to better engange with the community, we will be enabling the ideas center in the coming days.

Versienummer	3.2
Releasestatus	Final
Besturingssystemen	Scripttaal
Website	phpBB
Download	https://www.phpbb.com/community/viewtopic.php?f=14&t=2399606
Bestandsgrootte	7,15MB
Licentietype	GPL

Reacties (20)

Eindelijk over naar PHP7. phpBB was de reden dat ik het systeem nog op versie 5.6 moest houden, wat dan weer net aan ging met Mediawiki. Werd tijd!

Inderdaad erg onhandig. Ik had een vergelijkbare situatie, maar ik heb het opgelost door twee PHP versies naast elkaar te draaien en alleen requests voor phpBB naar PHP 5.6 te sturen, zo kon al het andere tenminste wel mee profiteren van PHP 7 Maar nu dat allemaal niet meer nodig is kan ik alles weer wat overzichtelijker inrichten.

Overigens leek het meeste van phpBB 3.1 wel aardig te werken in PHP 7, behalve de bbcode parser. Die maakte gebruik maakte van preg_replace functionaliteit die al een paar PHP versies deprecated was en nu niet meer ondersteund. Helaas is dat toch een essentieel onderdeel van phpBB, dus toen heb ik maar de bovenstaande oplossing gebruikt

Je kon meestal door handmatige code wijzigingen alsnog PHP 7 gebruiken.

Hier een vergelijkbare situatie. Zat echt op deze update te wachten... draaide wel 2 versies, 5.6 en 7. Alle overige sites waren al op 7. Vanochtend phpBB geüpdatet, alles getest met PHP 7 en net 5.6 van het systeem verwijderd

Eindelijk ja, phpBB was ooit een geweldig systeem, maar snel ingehaald door betere forumsystemen welke ook gratis zijn.

De Nederlandse site is trouwens ook geen reclame voor phpBB.Hun site is mobiel amper te bezoeken terwijl het forum by default responsive is. Kennis van de NL site is ook bedroevend slecht, op een enkeling na dan.

Ik speel er al een paar jaar niet meer met forum software, maar mijn ervaring was altijd dat phpBB gewoon het makkelijkste aan te passen was naar hoe jij het wou hebben. Dat ging met de alternatieven een stuk lastiger, die zaten vaak ook wat moeilijker in elkaar terwijl phpBB op het code niveau heel simpel in elkaar zat. Naast dat phpBB de beste mod/community support had.

Maar goed, dat kan ondertussen allemaal veranderd zijn.

Als we het over een tijdje terug hebben, had je myBB en SMF die gratis waren en zijn. Mods installeren? uploaden en klaar. Dat kon bij phpBB toen nog niet.
Nu kan dat met de meeste mods wel, maar dat heeft lang geduurd.

Er waren veel (heel veel) minder mods beschikbaar, en de mods installeren in phpBB was inderdaad niet zo simpel als bij sommige andere(bij de meeste was mods die conflicten hadden werkend krijgen wel een uitdaging), maar ik heb door o.a. phpBB PHP geleerd. En je kon de diffs ook automatisch laten gaan sinds versie 2.nogwat dacht ik, alhoewel dat soms problemen/conflicten gaf met andere mods.

SMF was een goed alternatief voor phpBB, ook veel mee gewerkt, maar dat heeft vrij lang geduurd voor dat een serieuze concurrent werd. En het was naar mijn mening gewoon wat lastiger om daar de code in te duiken.

Wat phpBB ook sterk maakte was dat het toen in ieder geval, veruit de meeste thema's had van alle bulletin boards die er bestonden.

Maar mijn informatie op dit onderwerp is al een paar jaar oud en zal nu outdated zijn, geen idee hoe phpBB er vandaag de dag voorstaat, toen ik er mee stopte werd phpBB juist net een beetje ingehaald door de concurrentie.

Het is redelijk modern nu. Alleen voelen themas nog erg oudbollig aan. Het standaard prosilver ziet er gewoon nog erg 2005 uit zeg maar.

Nu zijn er themas die er wel netjes uit zien met leuke ingebouwde functies.
Mods , extensies zijn er ook, alleen zit je steeds met updates dat deze niet werken, en je moet wachten op updates. Begrijpelijk, maar wanneer van tevoren belooft is dat extensies blijven werken, en ze na een update niet werken is behoorlijk teleurstellend. Dan heb ik het niet over 3rd party extensies, maar officiele van phpbb.com.

Pages mod, werkt nog niet met 3.2 wat wel beloofd was.

Maar goed, dit zal zeer snel worden opgelost, daar twijfel ik niet aan

Ik heb even een snelle blik geworpen op SMF (alweer), maar sinds een de laatste keer dat ik heb gekeken is er niks veranderd (een jaar geleden). Er zit zelfs nog code in die sinds 2003 niet meer is aangepast! (vroeger hete het YABB se), 'login2' (hallo oude vriend, dat is lang geleden zeg ) en ik weet als geen ander hoe dat eruit zag, ik heb toen een groot gedeelte van mijn eigen scripts gebaseerd op wat ik daaruit heb geleerd (dat is inmiddels wel anders)

Maar dat even terzijde, als ik kijk naar de huidige staat (en met name de aankomende 2.1) word ik niet goed. Het woord puinhoop beschrijft half nog niet hoe deze code is "onderhouden".

if (isset($_SERVER['HTTP_ACCEPT']) && strpos($_SERVER['HTTP_ACCEPT'], 'text/vnd.wap.wml') !== false)

WAT? Wab detectie (het mobiele web 0.1), wie gebruikt dit nog?
Legacy code is een recept voor problemen. Dat begint al lekker.

Maar dat was nog niet eens het ergste.

$token = md5(mt_rand() . session_id() . (string) microtime() . $modSettings['rand_seed']);

// ... even later

updateSettings(array('rand_seed' => microtime() * 1000000));

Werkelijk niet te geloven, dit is beveiliging voor beginners, als je nu vandaag de dag nog niet weet dat ik een vreselijk idee is, dan leef je echt onder een steen. Maar... het kan nog erger.

/**
* Nothing to see here. Move along.
*/
function clock()

WAT?

'db_escape_string' => 'addslashes',

Dit word gebruik in een legacy (lees dead code) onderdeel, maar daarmee heb je nog wel de kans dat er een Mod is die gebruik maakt van dit brakke stuk code. Daarnaast kan je dit heel makkelijk oplossen. Maar nu het pronkstuk (letterlijk stuk/kapot).

// Table crashed. Let's try to fix it.
elseif ($query_errno == 1016)

// ...

foreach ($fix_tables as $table)
$smcFunc['db_query']('', "
REPAIR TABLE $table", false, false);

Hier is alleen deze reactie op mogelijk: https://www.youtube.com/watch?v=H07zYvkNYL8

REPAIR TABLE vanuit een PHP script dat door iedereen kan worden aangeroepen?!!! WAT THE FU* AM I READING.

Race condition bij hoog bezoekers aantal (wat meestal de reden is van een crash zelf), het feit dat de applicatie zelf zijn eigen structuur mag aanpassen. En daarnaast is REPAIR TABLE bij MySQL (MyISAM) zeer foutgevoelig.

http://dev.mysql.com/doc/refman/5.5/en/repair-table.html

It is best to make a backup of a table before performing a table repair operation; under some circumstances the operation might cause data loss. Possible causes include but are not limited to file system errors. See Chapter 7, Backup and Recovery.

Dit ga je echt niet "even" live in productie uitvoeren, net zo eender als dat je je autobanden niet gaat vervangen tijdens het rijden. Hoewel dat nog minder gevaarlijk is..

Nee, echt, dit ga ik inlijsten. Zo'n vreselijk dom iets in een "populair" product? Dan was die broken random seed implementatie zo erg nog niet.

En nu ik dacht dat ik alles had gehad, blijkt dat ze wel degelijk weten dat BCRYPT bestaat, en dat niet alleen ze hebben de beste versie gekozen (van de auteur zelf). Zelfs Wordpress gebruikt (op dit moment) nog niet eens BCRYPT! Dus dat is wonderbaarlijk dan weer wel goed gedaan. Waarom de rest dan niet??

Over myBB, het ziet er niet veel beter uit dan SMF (op het eerste gezicht), myBB2 (unstable) is echter gebaseerd op Laravel en als het niet zoals phpBB compleet vastloopt op het idee dan heeft het zeker potentie.

Maar punt voor phpBB, het is misschien niet het meest moderne systeem (ten opzichte van myBB2) maar het is wel stabiel en gebruikt op dit moment al bepaalde onderdelen van Symfony (waar mogelijk), het grote plan om alles naar Symfony over te zetten is helaas (voor zover ik weet) gesneuveld, maar dan is het altijd nog beter dan SMF (TABLE REPAIR automatisch uitvoeren ik kan het nog steeds niet geloven).

[Reactie gewijzigd door s.stok op 8 januari 2017 16:00]

Hoi!
Je kan op GitHub altijd contributen naar de code; repo staat hier:
https://github.com/SimpleMachines/SMF2.1
Enkel een bug report/issue openen is natuurlijk prima als je geen tijd hebt om code voorstellen te maken.

Ff je commentaar, waarvoor dank , heel snel bekeken en snelle reactie; excuus als ik iets heb gemist of over 't hoofd zie;
1.) Je zegt dat het gaat om SMF 2.1, maar WAP mode is verwijderd in SMF 2.1 vziw. Ik heb nog ff een recursive grep gedraaid maar kom die code snippet inderdaad niet tegen. Waar kom je die code precies tegen? Weet je zeker dat je naar 2.1 kijkt en niet naar 2.0?
2.) Het tweede gedeelte van die snippet kan absoluut verbeterd worden. Voor het eerste gedeelte is token generatie erg lastig, en niet veel anders te doen om een unieke token te genereren.
3.) Dat is onderdeel van een easter egg.
4.) Hm ja, dat zit er inderdaad in voor legacy reasons/LTS. Toch moet dat moet eens bijgewerkt worden om het door een SMF functie heen te proppen, te loggen en dan return normal. D'accord.
5.) Welke race condition heb je het precies over...? De foutcode dat de tabel daadwerkelijk verrot is en een repair nodig heeft, komt van SQL zelf. Bij een hoog bezoekers aantal krijg je too many connections of gewoon een connection failure, maar krijg je geen errno terug van de server die stelt dat de tabel gecrashed is - en die is specifiek vereist om dat stukje code te triggeren. Derhalve wordt die code ook niet ge-execute. Ook bij het geval dat hoge bezoekersaantallen zorgen dat myISAM locked, dan krijg je enkel dat de boel moet wachten; maar krijg je nog steeds geen REPAIR omdat er geen crashed tabel wordt encountered. Al moet ik zeggen dat als je zoveel bezoekers hebt, dat je helemaal geen myISAM meer moet gebruiken maar al lang en breed op InnoDB hoort te draaien... De grote gebruikers (kanye west (jep...), nasa, burek, etc.) draaien wat aanpassingen. Voor de tienduizenden mensen die een hobby forumpje draaien en de ballen verstand hebben van databases, is die functie behoorlijk prettig - wat een repair zal sowieso gedraaid moeten worden. Ik ben het met je eens dat het op een grote database niet altijd wenselijk zal zijn dat een auto-repair wordt geïnitieerd; doch zit dit al jaren (misschien bijna 10 jaar, nu ik erover nadenk.) in de code en zijn er nooit klachten/problemen mee gemeld (eerder bedankjes omdat het forum zichzelf online wist te houden na crash.). Ik snap je visie, maar ben het niet echt met je conclusie eens dat het zo rampzalig is.

BCRYPT klopt inderdaad. De hash functie die in gebruik was, was nogal verouderd, dus die is vorig jaar compleet herschreven. Was nog even kloten, SMF wordt namelijk heel veel gedraaid in LTS systemen dankzij de enorme stabiliteit van de software en vrijwel perfecte security track record, vandaar dat PHP4 ook nog jarenlang ondersteund is geweest; en voor 2.0.x en 2.1 de vereisten flink opgeschroefd zijn. SMF 2.0.14 introduceert overigens PHP7 support.

Ik had hem hier gedownload http://download.simplemachines.org/
Ik kon de GitHub link op de website zo 123 niet vinden

Het tweede gedeelte van die snippet kan absoluut verbeterd worden. Voor het eerste gedeelte is token generatie erg lastig, en niet veel anders te doen om een unieke token te genereren.

http://php.net/random_bytes
https://github.com/paragonie/random_compat

Werkt zelfs met PHP 5.2 daarnaast is het algemeen bekend dat microtime alles behalve random is en het gebruik van md5 ook niet bepaald werkt.
Als je weet dat iets niet verstandig is kan je beter een todo/notitie achterlaten zodat iedereen dit vind (en hergebruikt) weet dat het moet worden aangepast.

Ik zie alleen dat het gebruikt word voor random-seeding, en later een token maar waar die token precies voor word gebruikt is mij niet bekend.
Daarnaast, als je dan al onvoorspelbaarheid wilt gebruik dan ook het IP, en sha1 (niet md5).

Overigens is dit niet enigste plek waar de Crypt compleet verkeerd word gebruikt.

https://github.com/Simple...es/LogInOut.php#L370-L371 (een 4 character salt? )

https://github.com/Simple...es/LogInOut.php#L370-L371 (een random password?)

https://github.com/Simple...es/Subs-Members.php#L1510 (geld er soms een character limiet of zo?! "Err. Whatcha doin' here.", ja precies... )

https://github.com/Simple...Sources/Subs-Auth.php#L45 (legacy support voor cookies? Kom op nou... )

https://github.com/Simple...ources/Subs-Auth.php#L594 (functie gebruik kan ik niet vinden met de zoekfunctie, dus ik ga uit van legacy. zo niet dan is er een groot probleem.)

https://github.com/Simple...Sources/Register.php#L567 (verkeerde controle van wachtwoord hash)

https://github.com/Simple...Sources/Register.php#L626 (token is technisch gelijk aan wachtwoord en moet met constante timing worden vergeleken, en overigens is 10 tekens echt te kort! geen vreselijk groot probleem, je kan hoogstens de registratie activatie omzeilen voor spamming maar toch een probleem).

Ik snap je visie, maar ben het niet echt met je conclusie eens dat het zo rampzalig is.

Een beetje oftopic.

Het probleem met MySQL is dat alles in MyISAM zonder transacties draait of iet, als het fout gaat zegt MySQL bekijk het maar!

Het feit dat dit kan gebeuren met data corruptie tot gevolg is al een unicum, alleen MyISAM heeft deze foutcode, geen enkele andere vendor of engine is zo foutgevoelig als MyISAM. Zelfs optimize kan je behoorlijk wat ellende opleveren, http://yapf.net/index.php..._raakt_.28alle_versies.29 en dat zelfde geintje heb je bij REPAIR (kans op disk full is vandaag de dag echter erg klein).

Een tussentijdse herstart kan je behoorlijk wat ellende opleveren.

If the server crashes during a REPAIR TABLE operation, it is essential after restarting it that you immediately execute another REPAIR TABLE statement for the table before performing any other operations on it. In the worst case, you might have a new clean index file without information about the data file, and then the next operation you perform could overwrite the data file. This is an unlikely but possible scenario that underscores the value of making a backup first.

En bij grote tabellen word het zelfs nog leuker, wat als iemand denkt "dit duurt te lang, bekijk het maar!" dan heb je geen garantie dat het proces nog doorloopt (zal ongetwijfeld wel , maar is niet gedocumenteerd of iets).

Dit risico nemen zonder dat je weet wat er precies gebeurd is te groot, daarnaast is er geen garantie dat het lukt. En als het al lukt heb je niet de garantie dat alle data nog aanwezig (of dat jet met een lage tabel zit).
Een fout automatisch oplossen is mooi maar soms heb je gewoon iemand nodig die het handmatig oplost.

http://stackoverflow.com/a/6177484

l MySQL doesn't really repair anything though, it just recreates the .myi files from scratch. Feel free to accept the answer if it solved your problem :-)

Het risico op race condtions is dat je bij te minste twee bezoekers (die op precies het zelfde moment, wat bij een hoog bezoekers aantal zeker aanwezig is) die actie uitvoeren je niet precies weet wat er gaat gebeuren (ja hij word wel is waar gecached, maar dat is geen garantie als je een bestand gebruikt (fall back)), doe hij het goed of loopt je systeem vast. MySQL waarschuwt er zelf al voor dit niet zomaar uit te voeren, en InnoDB is dan inderdaad een beter idee, maar niet iedereen is helaas zo slim en dan ben ik liever paranoia op wat je op zo'n moment doet.

"er nooit klachten/problemen mee gemeld", dat is alleen maar mooi maar geen garantie dat het altijd goed gaat

MySQL in MyISAM bij een hoge load (vooral oudere versies) willen nog wel eens crashen en dan loopt je tabel in de soep. En moet je REPAIR uitvoeren.

Enkel een bug report/issue openen is natuurlijk prima als je geen tijd hebt om code voorstellen te maken.

Geen tijd, en als ik iets wil toevoegen wil ik het wel goed doen en er zeker van zijn dat er niet ergens anders iets kapot gaat of dat mijn harde werk niet gebruikt word. Gezien de staat van de code is dat een onbegonnen werk voor mij, er zijn totaal geen unit tests of consistentie in de style, en tal van kleine beveiligingsproblemen die alleen met goede tests kunnen worden opgelost zonder het risico dat dit weer andere problemen introduceert.

Daarnaast zie ik dat een paar ontwikkelaars https://github.com/elkarte/Elkarte zijn gestart als fork en het daar beter (niet perfect) doen dan bij SMF.

Nog steeds wat off-topic

Allereerst hartelijk bedankt dat je de moeite en tijd hebt genomen om te kijken en mogelijke problemen aan te geven! Mooie reactie, dat wordt op prijs gesteld. Feedback is altijd goed, top dat je 't doet! Zouden meer mensen moeten doen, in meerdere projecten.

Ik ben het hier en daar met je eens, maar denk niet dat (al) de zaken die je noemt echt "security issue" schreeuwen, echter op een paar punten is er wel duidelijk wat verbetering nodig; vooral ook om het beter toekomstbestendig te maken, met al die snellere CPU's en voorspelbaardere unique id methodes. Ik denk dat een aantal dingen die je noemt veroorzaakt worden omdat je niet de hele codebase gelezen hebt. Begrijpelijk hoor, het zijn nogal wat regels code en het is inderdaad behoorlijk rommelig na jaren van voortborduren.

Korte reactie want net 6 uur lang naar een Terminal zitten gluren voor data recovery en geprobeerd een oude Cisco ASA remote te reanimeren; dus moe moe moe;
1.) Ik ga het eens overleggen m.b.t. die generator. Eventueel als het nodig blijkt, ik ken die functie niet goed, dan proppen we een geupgrade versie in B4; al is het alleen maar om het wat meer future-proof te maken.
2.3.) Die hash is niet in gebruik voor de wachtwoord functie, dus waarschijnlijk wat minder dramatisch dan je dacht. De size kan alsnog wel omhoog overigens, wordt bekeken.
Kijk bijvoorbeeld eens in Profile-Modify.php op regel 4057 en in LogInOut.php op lijn 565. =)
4.) Legacy format voor Cookies... Helemaal mee eens; dat is een probleem! Bedankt! Daar gaan we eens goed naar kijken. Als forms upgraden en mensen worden uitgelogd dan loggen ze maar lekker opnieuw in.
5.) (Subs-Auth.php#L594) Ik geloof dat dat stukje code wordt gebruikt om activatiecodes te bouwen. Die staan op de planning om te upgraden met betere hashing.
6.) (Register.php#L567) M.b.t. "verkeerde check van wachtwoord hash", ik heb ff zitten kijken; maar kan zo 1,2,3 niet zien wat er mis mee is. Het is laat, maar toch.
7.) (Register.php#L626) Akkoord! Ik geloof dat daar al naar gekeken werd en de planning is het te verhogen naar 35.
8.) Het hele myISAM verhaal - daar kom ik een andere keer op terug. Het blijkt echter dat er overwogen wordt om de functie default op 0 te zetten i.v.m. terugloop van myISAM gebruik; doch is niet echt geen haast bij vanwege 1) geen problemen 2) de functie kan uitgeschakeld worden. (autoFixDatabase = 0).

Mochten er punten overgenomen worden n.a.v. je aanbevelingen, dan zal ik er zorg voor dragen dat je een credit krijgt.
Als je iets anders dan je username hier wilt, of gewoon niet ge-credit wil worden, knal dan ff een DM mijn kant op als je wil.

Groet en nogmaals veel dank!

[Reactie gewijzigd door WhatsappHack op 10 januari 2017 06:27]

https://github.com/sstok is mijn profiel

Over punt 6, het wachtwoord word gecontroleerd als simpele string en niet met http://php.net/manual/en/function.hash-equals.php waardoor je een remote timing attack kan uitvoeren.

https://en.wikipedia.org/wiki/Timing_attack
http://blog.ircmaxell.com/2014/11/its-all-about-time.html

Mooi dat je deze adviezen overneemt niet iedereen is altijd even blij met nogal ongezouten mening dus ik ben blij dat ik toch heb kunnen helpen

Ohw ik was eerder een dingetje vergeten

Ik kon de GitHub link op de website zo 123 niet vinden

Het GitHub logo staat rechtsbovenin op de site. =D

Terug naar het gesprek:
Hmmm dat is best interessant...! Jup. Alleen wat ik even niet snap m.b.t. die timing attack in deze context he: is het dan niet zo, als ik het artikel nog eens goed lees, dat dit enkel uitmaakt als je de hash rechtstreeks vergelijkt zoals in de voorbeeldjes in dat artikel? Wij pakken sowieso al de user input en smijten er een salt eroverheen; en als er ook maar 1 karakter anders is krijg je natuurlijk een compleet andere hash te zien - niet 1tje die slechts één karakter verschilt...

Dus ook even in hele simpele vorm he; stel we doen

sha1($_GET['password']) == $user['password']

De timing aanval stelt dat we kunnen testen of

"x000000000000" == $user['password']

hoe lang dat er over doet om terug te komen en dan vervolgens doorgaan met

"x100000000000" == $user['password'];

Maar de hashes x000000000000 = 167dad5a9f10f00c71c1c4be43eb72e2740ab924 en x100000000000 == 6797010b4e44dc6593415f4858239a6c8d172a10. Dat klinkt niet alsof er een bijster makkelijke methode beschikbaar is om verder omhoog/omlaag te werken in de hash table? En als je 't zou proberen d.m.v. pre-hashing heb je 2 verschillende hashes te vergelijken...
Of ik zie ik nu echt iets heel doms over het hoofd?
(Zou me niet verbazen hoor, slechts 2.5 uur slaap en een opeens hele drukke dag doen een man geen wonderen.)
Zo'n aanval klinkt iig behoorlijk onpraktisch. o0 (Betekend niet dat het daarom totaal geen probleem is natuurlijk. Bij die andere functie, met maar 10 karakters voor de activatie code, zal het waarschijnlijk een groter probleem zijn.)

Overigens zit hash-equals er zo te zien pas in vanaf 5.6, en gezien een redelijke base nog niet geüpgraded heeft (altijd een fijn verhaal... maarja.) moeten we heel even wachten met de requirements omhoog schroeven - dat zal in de final waarschijnlijk wel gebeuren, nu is 't nog even lastig.

Maarrrrrr, ik denk dat het misschien even te patchen valt met een combat functie als het inderdaad een kwetsbaarheid is. Het lijkt me dat het heel moeilijk is te exploiten, maar toch... We gaan er iig nog eens uitgebreid naar kijken, bedankt!
En thanks voor de GitHub link.

Mooi dat je deze adviezen overneemt

Uiteraard! We zijn zeer geïnteresseerd in het veilig houden van de software. Grote fouten, kleine fouten, "dit is eigenlijk zowaar onmogelijk op afstand te spl0iten maar toch" fouten; rapporten erover zijn altijd welkom.

We hebben sowieso ook liever dat mensen hun zorgen uiten en dat het niet blijkt te kloppen (in het algemeen gezegd, even buiten dit alles ), dan dat ze niets zeggen bij een vermoeden en er blijkt een gapend gat in te zitten.

niet iedereen is altijd even blij met nogal ongezouten mening dus ik ben blij dat ik toch heb kunnen helpen

Oh, trust me... Daar weet ik alles van. Vraag maar aan sommige van onze mede-Tweakers.
Daar kan ik wel tegen, no problemo. =) Ik heb zelfs, weer even algemeen gezegd , liever een cynische/sarcastische/afzeikende post die de vinger op een (mogelijk) zere plek legt, dan iemand die super aardig probeert te doen en dan een probleem totaal niet bloot weet te leggen.

Don't worry.
En heel erg bedankt voor je hulp Ik laat het je nog wel weten als er iets uit voorkomt (die legacy cookie code en md5 gaan er sowieso uit lijkt me...), ik heb het op het bordje van de developers gedumpt - die gaan er verder naar kijken. Ook naar de andere dingen die je noemde overigens. Thnx!


-edit-
Fijn, die code tags werken niet in de comments. Even gefixed.

[Reactie gewijzigd door WhatsappHack op 11 januari 2017 01:26]

Welke dan?

Ben ook wel benieuwd. SMF was HET ding en aantal jaar geleden, daar is toen wat verandering uit ontstaan en nu zit 2.1 al 3 jaar in beta/ontwikkeling. 2.0 wordt nog wel netjes geupdate. Toen der tijd was PHPBB juist een leaky mess...

Verder komt mij dan meteen twee betaalde stukjes software naar boven IPB en vBullitin.

IPB en vBulletin zijn echter niet gratis

SMF staat niet bekend om z'n snelle ontwikkeling cycles, en heeft ook redelijke maling aan het commentaar erover. Stabiliteit, veiligheid en zeer uitgebreide tests is belangrijker dan nieuwe versies pushen. Beta 3 van 2.1 komt deze maand uit met bizar veel fixes en updates (al kan je al beyond beta 3 downloaden vanuit GitHub), en vanaf dat moment zal het heel snel gaan omdat de meeste issues daarin opgelost zijn en de feature locks bevestigd zijn.

Ik gebruik al jaren MyBB en daar ben ik erg tevreden mee.