Misschien he, misschien is het tijd om te stoppen met Log4j.
En misschien is het zinvol voor iedere ontwikkelaar om zichzelf af te vragen hoe het eigenlijk zit met de veiligheid van al de handige en gratis libraries die ze hun project in slepen.
En misschien is het verstandig voor organisaties om zicht te hebben op de applicaties die ze draaien (SBOM).
Misschien he.. misschien. Maar ja, wie ben ik om daar iets van te zeggen.

Ooit bouwde men veel zelf van de grond af op. Mischien moeten we meer terug naar die tijd. Veel eenvoudige basis functies kosten wat tijd om zelf te bouwen, andere kosten gewoon veel te veel tijd. Daarvoor kwmane er compilers.... en toen en toen

Haal je "fazzer" maar vast uit het vet.

Vroeger, toen iedereen nog met de hand assembly screef, was alles beter.

Scriptkiddiepraat

Valt dit niet gewoon onder consumenten software, wat nu in een Enterprise software stack gebruikt wordt?

Blijkbaar is het, ondanks dat iedereen de code kan zien, nog steeds niet gelukt om een veilige versie te maken.

Het zegt wel iets over de kwaliteit van dit stukje software, wat blijkbaar heel veel gebruikt wordt op Internet.

Yep, maar van de grond af opbouwen kost tijd en dus geld....Dat kan niet de bedoeling zijn.
Dus dan maar die handige libraries.....Iedereen dezelfde libraries....en dan komen we bij een probleem dat in de IT beveiligingswereld bekend staat als 'monoculturen'.
https://en.wikipedia.org/wiki/Monoculture_(computer_science)

En dan zou iedereen die met een nieuw project begint opnieuw het wiel gaan uitvinden. Dat kan inderdaad niet de bedoeling zijn en is enigszins vergelijkbaar met het overschrijven van boeken voor de boekdrukkunst maar dan nog erger want karma4 stelt eigenlijk voor dat iedereen maar het boek herschrijft vanaf scratch. Tja, moet je daar eigenlijk nog op ingaan?

Alles van de grond af opbouwen en telkens 'opnieuw het wiel uitvinden' is het andere uiterste. Dan heb je steeds weer opnieuw kinderziektes en fouten, dus daarmee gooi je het kind met het badwater weg.
Maar waar wel meer aandacht voor mag zijn, is diversiteit. Het is nu zo dat op sommige gebieden wel heel veel hetzelfde wordt gebruikt. Log4j is daar een goed voorbeeld van. Iedereen die wat met IT doet heeft er wel mee te maken. Van een spelletje (Minecraft) tot aan enterprise storage systemen.

Kortom: er is een middenweg tussen alles van de grond af opbouwen en iedereen dezelfde libraries gebruiken.

Nee, consumenten hebben totaal geen toepassing voor alles wat Log4j kan. Dat wil niet zeggen dat er niets op aan te merken is, ik vind 300.000 regels code voor logging extreem, zeker als dat allemaal aanwezig is in elke applicatie die het gebruikt, maar dit is geen consumentensoftware.

Het zijn, zoals Anoniem om 12:19 al schreef, uitersten. Bedenk dat veel programmeertalen die nu gebruikt worden bestaan omdat het wiel opnieuw is uitgevonden, en dat geldt ook voor allerlei applicatieframeworks. Elk besturingssysteem dat vandaag de dag in gebruik is is een voorbeeld van een wiel dat opnieuw is uitgevonden. Voor heel veel applicaties geldt dat de nu gebruikte alternatieven opnieuw uitgevonden wielen zijn terwijl de originelen allang in de vergetelheid zijn weggezakt. Er zou geen innovatie zijn als mensen niet zo eigenwijs waren dat ze het wiel opnieuw uitvinden.

Ik heb zelf als softwareontwikkelaar de tijd meegemaakt dat heel veel zelf van de grond werd opgebouwd. Ik ben het niet met karma4 eens dat we misschien weer terug moeten naar die tijd, maar dat wil niet zeggen dat alles nu altijd beter gaat.

Ik heb, als ontwikkelaar die op een gegeven moment ook te maken kreeg met het wél beschikbaar zijn van steeds meer niet zelf gemaakte softwarecomponenten, een stevige weerzin ontwikkeld tegen het nonchalante, kritiekloze gemak waarmee maar van alles werd binnengesleept.

Er worden abstractielagen op abstractielagen op abstractielagen gestapeld, en dat is aantrekkelijk omdat dingen makkelijker zouden worden erdoor. Maar die abstractielagen hebben zelf weer de neiging om uit te groeien tot alleskunners, en ik heb meer dan eens geconstateerd dat als ik, voor waar ik het voor nodig had:
• de low-level-interface waar de abstractielaag je van afschermde eigenlijk makkelijker en overzichtelijker was dan die abstractielaag;
• de low-level-interface alles kon wat ik nodig had terwijl sommige belangrijke dingen voor mijn toepassing ontbraken in de abstractielaag, en een crime waren om erin voor elkaar te krijgen;
• de abstractielaag ontzettend veel dingen kon die totaal misplaatst waren in mijn toepassing en potentieel een securityrisico op konden leveren, domweg omdat code die dingen kan die vooral niet moeten aanwezig is in de runtime;
• ik als gevolg van alle voorgaande punten veel beter snapte hoe de applicatie werkte door de low-level-interface te gebruiken dan met de abstractielaag, en ook dat heeft een directe impact op security.

Ik heb gebotst over dit soort dingen met collega-ontwikkelaars die het volslagen belachelijk vonden dat ik het wiel opnieuw ging uitvinden terwijl er een kant en klare oplossing was. Dat die "oplossing" niet eens ondersteunde wat nodig was, van alles meesleepte wat beter afwezig kon zijn, en ook nog eens helemaal niet eenvoudiger was, dat alles was voor die anderen op de een of andere reden geen argument.

Bij Log4j zijn de 300.000 regels broncode die je je applicatie insleept voor alleen logging iets dat bij mij alarmbellen doet afgaan. Daar moet ontzettend veel inzitten waar je helemaal geen boodschap aan hebt in veel applicaties. Het komt daardoor op mij over als een ernstig geval van overengineering. Die verdenking heeft het voor mij in ieder geval. Er zijn applicaties waarin het vermoedelijk minder werk is om het wiel wél opnieuw uit te vinden dan om te doorgronden wat het gebruik van Log4j precies aan risico's met zich meebrengt.

300.000 regels code voor een library die enkel hoeft te zorgen dat er wat logging wordt weggeschreven?? Is er nog ergens iemand die aan Software Quality Assurance doet?