Yep. Tot nu toe waren er niet veel mensen die spontaan zulke code controleerden. Zou ook mijn hobby niet zijn om het puin van een ander op te ruimen. Bij wijze van spreken: meestal creëer je liever je eigen "kindjes" dan op kinderen van anderen te letten... Echter nu aan het licht is gekomen dat dit heel nuttig werk is, hoop ik dat we hier samen toch een beetje anders over gaan denken.

In principe is dit de fout van de grote bedijven die massaal de code gebruiken maar er verder niet naar om kijken.

Als je software van Red Hat/IBM/Cisco/Google/Apple/Oracle/etc/etc/ koopt mag je toch aannemen dat ze er ook eens naar gekeken hebben. Waar betaal je dan al dat geld voor?

Oracle zijn "unbreakable linux" is dus echt alleen maar een marketing praatje. Iets voor de Reclame Code Commissie? ;-)

Wat ik in de eerste reactie lees is dat het vaak meer werk is om je te verdiepen in het werk van anderen en daar evt
nog fouten uit te halen dan om zelf wat te maken. Dat herken ik van library code maar dat is toch wat anders.

De tweede reactie is meer "ik betaal dus moet het wel goed zitten". Als je iets van Cisco koopt dan betaal je dik maar
je hebt geen inzage in de source dus je weet niet echt of het wel goed zit. Dat neem je alleen maar aan, omdat je niet
alles kunt uitzoeken.

Paar problemen met open-source:
- Blind vertrouwen
- Aansprakelijkheid
- Net zo makkelijk om naar lekken te zoeken ZONDER deze te publiceren (VUPEN)
- Vaak niet de moeite waard om er geld voor te vragen (hobby-projecten)

Er zijn uitzonderingen natuurlijk, maar die bevestigen wel de regel.

Ik denk dat die gedachte typerend is voor bedrijfsvoering: We kopen iets in dus kunnen we erop vertrouwen dat de leverancier zijn werk heeft gedaan. En als er iets misgaat kunnen we met onze vinger wijzen, en een dikke schadeclaim neerleggen. Probleem is alleen dat dat in de IT niet echt werkt, omdat iedereen NO WARRANTY hanteert in de licentievoorwaarden, wat bovendien ook nog eens heel normaal wordt gevonden.

Ik werk ook al jaren in een open source project. Een aantal files uit dat project ken ik bijna uit het hoofd, maar er zitten ook wel een stuk of 100 files in het project in waar ik nog nooit in gekeken heb. En ook in de goed bekeken files kom je soms fouten tegen die er al jaren in zitten. Alleen de 'crashing' bugs vind je snel.

Voor mij is het ook een illusie dat open source per definitie veiliger is. Er zijn meer mensen die er fouten uit kunnen halen dan bij gesloten software. Maar de mensen die de lekken vinden zitten in beide kampen…

"In principe is dit de fout van de grote bedijven die massaal de code gebruiken maar er verder niet naar om kijken."

Indien jij een open source pakket gebruikt, gemaakt door particulieren, dan is het de schuld van grote bedrijven indien je kwetsbaar bent ? Of wat wil je nou eigenlijk zeggen ? ;)

"Als je software van Red Hat/IBM/Cisco/Google/Apple/Oracle/etc/etc/ koopt mag je toch aannemen dat ze er ook eens naar gekeken hebben. Waar betaal je dan al dat geld voor?"

Software programmeren blijft mensenwerk, ongeacht of het gaat om open source software. Indien je denkt dat er foutloos geprogrammeerd kan worden, zolang het werk uitgevoerd wordt door een commercieel bedrijf, dan ben je redelijk naief.

Ik denk dat het aangehaalde voorbeeld, OpenSSL, een slecht voorbeeld is voor de stelling "niemand kijkt naar open source". Om OpenSSL te kunnen begrijpen moet je (erg) goed zijn in wiskunde, encryptie, beveiliging. Er zijn niet zoveel mensen wereldwijd die deze vereiste disciplines in 1 persoon verenigen. Neem dan als voorbeeld Apache. Of ga de stelling eens onderbouwen met bewijsvoering. Neem als voorbeeld de diverse bug-forums van diverse open source projecten, en ga eens turfen hoeveel mensen daadwerkelijk een bijdragen leveren. Na die wellicht saaie actie heb je getallen om de stelling te bewijzen dan wel te ontkrachten.

Wat zit deze vent nu te zagen? Misschien klopt het wat hij zegt, maar misschien ook niet. Maar feit is dat dergelijke problemen altijd zo snel als mogelijk opgelost worden. Woensdag geconstateerd, vrijdag al gedicht. Ik vind dat klasse! En verder blijft programmeren mensenwerk, dus in al die miljoenen regels code zal er wel ergens een foutje in zitten. Mag het ook? Belangrijker is dat er adequaat op gereageerd wordt. En de open source wereld heeft andermaal aangetoond dat ze razendsnel handelen bij dergelijke kwetsbaarheden. Dat is nog eens wat anders dan "Patch Tuesday", waarbij je systeem soms weken achtereen kwetsbaar blijft voor de dan al bekende lekken. Geen geruststellende gedachte als je Windows draait (om even een voorbeeld te geven)...

Vrijdag gedicht, woensdag geconstateerd door het publiek, jaren geleden geconstateerd door inlichtingendiensten en tot vrijdag door hen misbruikt (bij wijze van spreken). De snelle response is een goede prestatie, maar met snelle response alleen ben je zeker niet veilig.

Gaat ook op voor, proprietary code.

Dat ligt er aan wat je bedoelt met "niet werkt". Het gaat er bij een directeur niet om of dat er daadwerkelijk een probleem
is, maar alleen in hoeverre dat zijn eigen positie en financien aantast. Als je een accountant in huis hebt dan vraagt die
hoe je al dit soort dingen geregeld hebt. "heeft u een firewall?". "ja hoor een van cisco". En dan komt er een vinkje
te staan bij "alles in orde". Zeg je "ja hoor een opensource systeem" dan komen er allemaal vragen en komt er een
extra risicopuntje bij IT beveiliging te staan.

In beide gevallen kan er ingebroken worden. Maar in het eerste geval is het "maar die hackers komen tegenwoordig
overal binnen daar is niks aan te doen" en in het tweede geval is er een onverantwoorde management beslissing genomen
waar consequenties uit moeten volgen. Dat wil men niet dus koopt men Cisco.

Ik weet het, het heeft niks met werkelijke risico's te maken maar zo gaat het wel. Wellicht dat er tegenwoordig IETS
meer waardering is voor opensource oplossingen maar ik heb het bovenstaande al vaak gezien bij IT-scans, men houdt
er gewoon niet van als je geen mainstream commerciele spullen hebt. En niet alleen op dit soort veiligheids gebied
hoor, ook op gebied van continuiteit en andere risico's wordt de de-facto standaard commerciele oplossing vaak meer
waardering gegeven dan eigen knutselwerk of opensource spullen, onafhankelijk van de daadwerkelijke kwaliteit.

Liever een gammele Windows oplossing (want daar werkt iedereen mee) dan een rocksolid opensource oplossing waarvan
het nog maar de vraag is of die volgend jaar nog ondersteund kan worden.

Het is juist een heel goed voorbeeld, want die gigantische bug die er laatst uit gehaald was die had nada niks te maken
met wiskunde, encryptie of beveiliging maar was gewoon een voorbeeld van een dood ordinaire memory boundary checking
fout.

En die werd dus NIET meteen gevonden. Kun je nagaan hoe het zou gaan met een echt lastig wiskunding probleem.

Hoezo is dit zo zeer een argument tegen open source? Deze bug zou ook in closed source kunnen zitten, maar nu is het in ieder geval eruit gehaald. Bij een closed source programma zou dit er voor altijd in kunnen blijven zitten.

Maar meer dan closed source :)

Oracle verkocht vroeger haar oplossing op basis van Red Hat.
Nu doen ze dat ook maar hebben ze een "fork" van Red Hat gemaakt, eigen naampje gegeven, maar ondertussen gebruiken ze wel R&D van Red Hat.... het is bijna een CentOS (vrijwel 100% binary compatible).

In plaats dat Oracle klanten nu licenties en support contracten bij Red Hat dienen af te nemen doen ze het nu bij Oracle, wat eigenlijk best smerige streek is.

Maar gelukkig zijn er bedrijven die er een dual-vendor policy op na houden en deze vendor lockin zullen voorkomen.

Overigens met MySQL zijn ze nu ook al een tijdje bezig.... eerst onschuldig door bugs, release fixes niet/nauwelijks/laat te publiceren en langzaam maar zeker om closed source spullen er in te zetten.

De tijd dat men massaal op laag niveau naar code kijken is voorbij, het probleem is dat in derde wereldlanden er vele malen meer ICT ingenieurs afstuderen dan in het "Westen", waardoor je daar meer kennis hebt, deze mensen willen allemaal een betere toekomst voor zichzelf en zullen goedschiks of kwaadschiks hun kennis gaan toepassen.

En daar kan het westen helemaal niets tegen doen.

Dus af en toe zullen er grote bugs bekend worden, maar zodra het bekend is moet men zich er niet druk over maken.
Waar men zich wel zorgen over moet maken is de hoeveelheid zerodays die nu bij overheden en kwaadwillenden bekend zijn en mogelijk te nimmer (of per ongeluk) ooit een gevonden en geopenbaard zullen worden.

Vroeger had men full disclosure en white hat hacking moeten aanmoedigen en belonen, zodat men vandaag de dag niet telkens achter de feiten aan hoeft te hollen, van incident naar incident.... want dat is structureel (en helaas) acceptabel geworden.

Volgens mij zit de bug er anders nog steeds in..... Zelfs na 2 updates heeft men het nog steeds niet kunnen oplossen. De vraag is op de bug ook wel op te lossen is zonder grote impact.
Waarbij de updates ook nog eens heel goed getest moeten worden.

Graham stelt dat de uitspraak "many eyes make bugs shallow" overtuigend onderuitgehaald is. Maar hij constateert wel dat nu, naar aanleiding van het probeem, de bash-code wél door veel mensen wordt bekeken en dat die ook van alles vinden. Opeens werken de "many eyes" dus juist wel.

Openbaarheid van de broncode is een voorwaarde voor de "many eyes" die de broncode inspecteren, maar geen garantie. Om daadwerkelijk code in te duiken moet iemand een reden hebben om dat interessant te vinden. Die interesse is er op dit moment voor bash en dat zou uiteindelijk wel eens kunnen resulteren in meer verholpen problemen dan wanneer de code niet openbaar was geweest.

"Many eyes make bugs shallow" is niet waar als je denkt dat die ogen volautomatisch naar de code kijken omdat het niet wordt tegengehouden. Maar als er daadwerkelijk gekeken wordt levert het ook daadwerkelijk wat op. Het voordeel van open source is dat dat onbeperkt kán, niet dat het automatisch gebeurt.