Als je open source als gratis leverancier ziet, dan krijg je dus dit

Enige ophef op Twitter: OSS-developer Daniel Stenberg kreeg een nogal bars klinkende mail van een gebruiker, die hem als “Maxx Team Partner” aanschreef en graag binnen 24 uur wilde horen hoe zijn bedrijf was ingericht op het afdekken van risico’s rondom de enorme log4j bug van onlangs. “What is the timeline for completing remediation? List the steps, including dates for each.” Eh. Als ik daar leverancier was, zou ik dit niet heel lief vinden. Maar als je enkel iets op internet had gezet?

Het enige logische antwoord is wat Stenberg ook gaf: “I’d be happy to answer all the questions as soon as we have a support contract.” De algemene tip die ik al eerder aanried: OSS drijft op de gedachte van communities. Iedereen helpt elkaar, en daar kan iedereen dus terecht. Maar bedrijven werken met contracten, om zekerheid (althans, de illusie van) te realiseren en om leveranciers bij de nekharen te kunnen grijpen als blijkt dat er iets misging. A throat to choke, extern de schuld neerleggen zeg maar.

Open source licenties zijn natuurlijk contracten, dus als je als bedrijf software van Stenberg installeert (hij maakte onder meer cURL) dan heb je een leveranciersrelatie. Zou je kunnen zeggen als rechtlijnige inkoper. Maar er is dan in het geheel geen sprake van zelfs maar enige inspanningsplicht bij Stenberg, hier is de software en als ‘ie breekt, mag je de stukjes houden. Of zelf aanpassen, zie maar. Dat is de gedachte achter open source: je kunt er zelf mee aan de slag, veel plezier verder.

Ondertussen zijn we denk ik op het punt dat dit geen groot risico meer zou moeten zijn. Veel bedrijven stoppen hun interne pipeline en producten dan ook vol met open source, en ontdekken pas de problemen als er dingen zoals log4j zich voordoen: een kwetsbaarheid in een breed gebruikt stuk software, dat eigenlijk nauwelijks onderhouden wordt omdat die ene aardige man uit Nebraska er niet zo’n zin meer in heeft.

Helaas verbaast het me toch niet dat je zo’n reactie krijgt van een bedrijf dat al jaren gratis die software gebruikt. Het is natuurlijk juridisch complete onzin, je hebt niets te eisen als je geen afspraak over dat onderwerp hebt gemaakt. En zeker waar het gaat om gratis aangeboden software waarbij nadrukkelijk geen enkele verwachting werd gewekt, is dit ook nog eens moreel niet zo netjes. Maar ik snap het wel, dat is nu eenmaal de reflex waar je mee komt als je software van derden gebruikt die lek blijkt te zijn.

Toch zou het goed zijn als organisaties wat vaker op zoek gaan naar mogelijkheden om OSS projecten te sponsoren. Niet perse als dure SLA, maar betalen voor een stuk ontwikkeling voor de toekomst of een preventieve securityscan, het zou geen gek idee zijn. Natuurlijk, daar profiteert de concurrent dan weer van, maar we hebben het hier over software die per definitie geen competitief voordeel geeft, dus of dat nou de ergste reden moet zijn?

Arnoud

25 reacties

  1. Je hebt geen enkel recht op een antwoord. Je zou vriendelijk kunnen vragen, of de ontwikkelaar toevallig de lekke versie van log4j heeft ingebouwd. Wanneer daar een ja op komt, kun je met de ontwikkelaar overleggen, op welke manier dit aangepast kan worden en welke (financiële) bijdrage je daaraan kunt leveren. Dan maak je duidelijk dat een oplossing nodig is, maar leg je de last niet bij de ontwikkelaar. En verder, lees eerst eens de gebruiksvoorwaarden, voordat je dit soort vragen gaat stellen. Staat daar geen ondersteuning in, dan kun je die ook niet vragen, laat staan eisen.

  2. @Eelco, het is natuurlijk niet in de haak wat die developer heeft gedaan. Het lijkt me dan ook dat je met zo’n actie een behoorlijk risico loopt dat je een schadevergoeding zal moeten betalen. Je kan in je softwarelicentie veel verantwoordelijkheden uitsluiten maar kwade opzet niet.

  3. Het ergelijke is dat ik bepaalde open-source software niet mag gebruiken omdat er geen SLA contract afgesloten kan worden. Ondertussen is die gratis open-source software beter dan de dure software met SLA die mijn baas wel aanschaft.

    Ik snap het ergens wel, maar toch.

    1. Er is geen enkel probleem voor een bedrijf om zo’n contract te sluiten waarbij de support organisatie belooft om te upstreamen en te onderhouden etc. Het is open source, iedereen kan en mag een afgeleid werk maken en daarvoor onderhoudscontracten sluiten. Wellicht betekend dit dat je specifieke versies moet gebruiken of het via de contractant moet verkrijgen (voor eventuele patches), maar het kan juridisch en economisch wel.

  4. Je zou dit als een argument tegen open source kunnen zien! Doordat bedrijven gewoon maar open source producten bij elkaar grijpen en samenvoegen kunnen er enorm kwetsbare systemen ontstaan daar de malware welig tussen tiert. Je hebt immers geen garantie als de boek uiteindelijk kwetsbaar blijkt en je kunt ook niet snel de schuld bij de leverancier van de software leggen, want die gaf geen garantie. Kortom, moeten we open source nog wel willen, als dit betekent dat we zelf de verantwoording krijgen voor eventuele schade achteraf?

    Zo maak ik mij bijvoorbeeld bij web development zorgen om de toenemende populariteit van web frameworks zoals React en Angular en het onderliggende NodeJS. Dit zijn hele mooie technieken en allemaal op basis van Javascript, maar hoe weet ik dat er geen gekke dingen gebeuren in die code? Want als je project binnen twee weken klaar moet zijn en je moet alle code van deze frameworks controleren dan is dat een onmogelijke taak. Je moet er dan op vertrouwen dat anderen dat wel voor je hebben gedaan. Helaas verwachten die anderen dat ook en dan krijg je het Log4j probleem: niemand die beseft dat het systeem kwetsbaar is omdat niemand er echt naar kijkt…

    Natuurlijk kunnen er commerciële bedrijven opstaan die ondersteuning bieden voor open-source projecten. Alleen, gaan die wel de kwaliteit van de code controleren? En gaan ze ook de kwetsbaarheden in de code verbeteren en terugvoeren aan de oorspronkelijke auteur? Of maken ze gewoon een eigen branch die ze dan meer commercieel opleveren binnen de mogelijkheden van de oorspronkelijke licentie? En kunnen ze wel verantwoordelijk gehouden worden voor eventuele schade?

    1. Als je commerciële ondersteuning biedt schept dat verplichtingen. Dus ook een zekere aansprakelijkheid, maar je kunt in je serviceovereenkomst bepalen hoe ver je aansprakelijkheid gaat. In veel gevallen leveren de aanbieders van servicecontracten ook bijdragen aan de Open Source projecten waar ze ondersteuning voor bieden.

      En ja, ik maak me ook zorgen, met name met het gemak waarmee tientallen bibliotheken per project automatisch van servers gedownload worden, waarbij niet eens gecontroleerd wordt of de bibliotheek de versie is die je verwacht en niet een variant met malware die door een stel hackers is neergezet.

      Ook een leuke juridische vraag: wie kan in een dergelijke situatie aansprakelijk gesteld worden? De auteur/samensteller van de (oorspronkelijke) bibliotheek? Of het platform dat de verspreiding doet?

      1. En ja, ik maak me ook zorgen, met name met het gemak waarmee tientallen bibliotheken per project automatisch van servers gedownload worden, waarbij niet eens gecontroleerd wordt of de bibliotheek de versie is die je verwacht en niet een variant met malware die door een stel hackers is neergezet.

        Het is nog erger dan dat soms, omdat de automatische download ook een update mee kan nemen die je bestaande code doet crashen! Ik had in het verleden een web applicatie die van Bootstrap 3 gebruik maakte, waarbij deze per ongeluk naar een nieuwere versie een upgrade kreeg naar 4 en gelijk alles de mist in ging omdat bepaalde onderdelen waren hernoemd of verwijderd.

        Op The Daily WTF was laatst nog een artikel over dergelijke ongewenste upgrades en dan in een cloud-dienst. De Athena service van Amazon kreeg een paar wijzigingen in hun SQL syntax waardoor deze zich anders ging gedragen dan voorheen. Dit waren veranderingen die maar weinig problemen op zouden moeten leveren, maar desondanks best veel problemen kunnen veroorzaken.

        En omdat ik veel met Visual Studio werk heb ik daardoor ook veel NuGet bibliotheken nodig. En die krijgen wel eens updates en upgrades. Als je die niet installeert dan heeft je project mogelijke kwetsbaarheden. Als je ze wel installeert dan breekt mogelijk een deel van je code door die wijziging! Het Entity Framework staat hierom bekend, ook al is het een behoorlijk krachtige oplossing. Alleen, soms compileert je project niet meer omdat een attribuut is hernoemd of omdat een stukje code is verwijderd. Heel irritant…

        Het probleem met open source is dat de auteur gewoon geen rekening mee hoeft te houden met wat de gebruikers ervan er mee doen. De auteur heeft immers geen contract met hen en hoeft ook niet te garanderen dat de boel na iedere update nog gewoon goed werkt zonder problemen. Immers, het project is zijn eigen speeltje en hij is zo vriendelijk dat anderen er ook mee mogen spelen, maar de auteur blijft de baas. En wie daar problemen mee heeft moet maar een eigen branch van de code bijhouden en daarbij een andere naam kiezen, want die auteur heeft de naam al als handelsmerk.

        Ja, het is wel mooi dat er dankzij Open Source veel code voor iedereen beschikbaar komt, maar daar zit vaak ook veel vuiligheid en slechte code tussen. En je moet maar hopen dat iemand het opruimt voor je het zelf gebruikt…

        1. Het probleem met open source is dat de auteur gewoon geen rekening mee hoeft te houden met wat de gebruikers ervan er mee doen. De auteur heeft immers geen contract met hen en hoeft ook niet te garanderen dat de boel na iedere update nog gewoon goed werkt zonder problemen. Immers, het project is zijn eigen speeltje en hij is zo vriendelijk dat anderen er ook mee mogen spelen, maar de auteur blijft de baas.

          Dat is niet altijd zo. RedHat en Ubuntu (om een paar voorbeelden te noemen) hebben Open Source ontwikkelaars in dienst (genomen) om software voor hun klanten te onderhouden. Deze ontwikkelaars hebben wel degelijk rekening te houden met wat de gebruikers willen. En daarnaast is er ook bij Open Source een marktwerking: projecten met en goede naam trekken meer gebruikers en ontwikkelaars. En het is meerdere malen voorgekomen dat een groep ontwikkelaars een pakket heeft overgenomen van een eerdere auteur die geen zin meer had in het onderhoud.

          Met “commerciële” software overgeleverd aan wat de leverancier je aanbiedt aan ondersteuning. Als die je in een “upgrade treadmill” wil hebben kom je daar niet makkelijk uit. Bugs fixen is ondoenlijk als je geen toegang tot broncode en compilatieomgeving hebt; wat dat betreft ben je bij Open Source beter af. (Mits je de benodigde kennis hebt of kunt inhuren.)

          1. Deze ontwikkelaars hebben wel degelijk rekening te houden met wat de gebruikers willen.

            Meh. RedHat en Ubuntu zijn commerciële bedrijven die naast open source ook betaalde diensten leveren en hun aansprakelijkheid is dan ook beperkt tot het deel dat in je contract met hen staat. Als je dus een gratis Ubuntu versie gebruikt dan heb je nog steeds geen rechten als er problemen blijken te zijn.

            Op dit moment wordt Linux geplaagd door een ander kritische bug: De PolKit tool is al 12 jaar lang kwetsbaar ook al valt de schade nog enigszins mee. En ja, Red Hat en Ubuntu zullen daar eigenlijk iets aan moeten doen, en ze hebben ook een patch uitgegeven. En hoewel David Zeuthen van Red Hat het heeft ontwikkeld is het gewoon een open source project en dus zonder garantie. (Onderdeel van freedesktop.)

            Ik vraag mij dan ook af hoeveel andere bugs er nog zijn in Linux en andere open source projecten en ik denk dat Red Hat en Ubuntu de gebruikers er gewoon op wijzen dat dit soort onderdelen niet onder de garantie vallen vanwege de kleine lettertjes in het contract. Ze brengen een patch uit en vertellen je deze te installeren. Maar verder moet je het toch echt zelf uitzoeken.

            Waarbij ik er even fijntjes op wijs dat ook de grote Linux distributies gewoon hun eigen upgrade-systemen hebben die relatief automatisch al updates kunnen uitvoeren of je vertellen dat je een update moet uitvoeren. Bij Linux ben je daarnaast overgeleverd aan tientallen open source projecten die allen hun eigen updates kennen en waarbij je als beheerder continu al die projecten in de gaten moet houden voor nieuwe updates. Zelfs de kernel is een verzameling van diverse projecten bij elkaar waarbij veel gebruikers eigenlijk afhankelijk zijn van diegene die een distributie heeft gemaakt om de updates bij te houden. Of een van de vele package management systems die er bestaan, zoals APT. Maar dan kom je bij de kern van het probleem, namelijk een toepassing die ongecontroleerd wijzigingen kan uitvoeren op je systeem zoals commerciële bedrijven ook gewoon updates uitvoeren. Maar de commerciële bedrijven kun je terugfluiten als hun update jouw systeem breekt en dat mogen zij dan oplossen. Bij open source heb je eigenlijk geen echte rechten, want het is je eigen risico.

            Ik denk dan b.v. terug aan het Sony Rootkit schandaal waarbij Sony stiekem een rootkit mee installeerde met hun software, alleen was deze kwetsbaar voor malware. En Sony heeft daar zwaar schade onder geleden, inclusief vele schikkingen met slachtoffers. Maar de log4j bug is ook een schandaal, alleen kan je daar de maker niet aansprakelijk voor stellen. Ja, zelfs de Amerikaanse Overheid is hierover extreem boos, maar ook zei weten dat de auteur niet verantwoordelijk gehouden kan worden. Qua ernst is log4j veel ernstiger dan de Sony Rootkit, maar juridisch heeft Sony er veel meer problemen mee dan Ceki Gülcü, die de log4j utility heeft ontwikkeld en daarbij bewust code heeft gebruikt die uiteindelijk tot kwetsbaarheden konden leiden. (Omdat hij het wel handig vond dat je andere Java-modulen kon aanroepen vanuit je log-berichten.)

            Het verschil is gewoon simpel: er gaat iets mis en een commerciële leverancier kun je dan aansprakelijk houden maar een open source leverancier niet. (Tenzij je een contract afsluit, maar dan is het geen open source meer!)

            1. Open Source is een aspect van de licentiekeuze die de auteur van een pakket maakt. De keus voor een Open Source licentie betekent dat de code door o.a. Red Hat en Debian aangepast en verspreid kan worden.

              De (service-)overeenkomst die een gebruiker met Red Hat sluit staat los van de licentie die de gebruiker van de originele auteur krijgt. Als in die service-overeenkomst staat dat Red Hat een inspanningsverplichting heeft om bepaalde bugs te fixen is Red Hat daaraan te houden.

              Het zou me niet verbazen als “gevolgschade” van bugs uitgesloten is van aansprakelijkheid, dat doen de commerciële softwarebakkers ook. Mijn ervaring met “apt” is dat ik in controle ben bij het doen van updates (cryptografisch ondertekend namens Debian en alle updates in een). Op het Windows-platform heeft iedere leverancier zijn eigen “oplossing” en is het veel langer uitzoeken wat er allemaal gepatcht moet worden.

              1. Als in die service-overeenkomst staat dat Red Hat een inspanningsverplichting heeft om bepaalde bugs te fixen is Red Hat daaraan te houden.

                Maar dat geldt in principe alleen voor betalende klanten, niet voor de rest. En daarnaast moet het dan wel in het contract staan en ik vraag mij af of dit ook echt het geval is. Maar goed, als je dat wilt uitzoeken, graag. Ik vind daar eigenlijk weinig tot niets over terug op de websites van Red Hat en Ubuntu. Als ik b.v. bij Red Hat een account aanmaak en nakijk dan is dit nog steeds onduidelijk. Kan er wel de Red Hat Enterprise Linux Server kopen met support, wat betekent dat ik met hen kan bellen met vragen als ik de duurdere opties kies. Maar geen beloftes dat ze bugs in Linux en onderdelen oplossen of zelfs maar aansprakelijk zijn voor schade die door deze bugs worden veroorzaakt. Die PolKit-bug blijft dan nog steeds mijn probleem. Als een kwade medewerker daar misbruik van maakt en mijn gehele Linux-server formatteert nadat hij root-rechten verkreeg dan heb ik nog steeds pech.

                Kortom, met je subscription die je voor een jaar krijgt, koop je gewoon gebakken lucht. Ja, je kan dan bellen met vragen en hopelijk lossen ze die op, zoals ieder commercieel bedrijf dat doet. En ze zullen een patch uitgeven als er een kwetsbaarheid blijkt te bestaan. Maar verder?

                Het zou me niet verbazen als “gevolgschade” van bugs uitgesloten is van aansprakelijkheid, dat doen de commerciële softwarebakkers ook.
                Zou mij ook niet verbazen, maar de maker van het product kan in principe wel verantwoordelijk gehouden worden. Zo werd er in het verleden al een roep om compensatie geuit nadat een Windows 10 update voor problemen zorgde. Zo heeft Microsoft €1.100 moeten betalen ter compensatie van een Finse gebruiker nadat een ongevraagde upgrade van Windows 8 naar 10 schade veroorzaakte. Maar omdat je Windows-licenties in principe koopt kun je dus alsnog een claim indienen. Bij open source koop je niets. Je krijgt iets om uit te proberen op eigen risico. Het is niet iets wat je koopt en daarna van mag verwachten dat het goed werkt.

                En dan kun je wel ergens een service-contract afsluiten als je hulp nodig hebt, maar ook dan kun je de schadeclaim nergens kwijt. Da’s het mooie van open source, want de maker is vrijwel niet verantwoordelijk te stellen. (Alleen als er overduidelijk kwaadaardige code is geleverd.)

              1. Tot mijn verbazing vond ik vorig jaar bugs in de zeer basic en veelgebruikte clibc van GNU, één bug die grote traagheid veroorzaakte, en een andere waardoor je zelfs een eindeloze lus krijgt, met legitieme C-code. Ik meldde die bugs, maar er is maanden later nog steeds NIETS mee gedaan, kennelijk zelfs niet eens naar gekeken.

                bug 28277 en bug 28258.

                Ik had toch iets meer kwaliteit en assertiviteit verwacht in zulke code, dus bijna in alle andere software gebruikt wordt. Gelukkig vond ik workarounds die op alle platformen werken, maar toch …

                  1. https://en.wikipedia.org/wiki/Musl is een veel betere library, met wel schone en mooie C-code, zeker vergeleken met het nogal ondoorgrondelijke spul van GNU. En in musl zitten die bug en de traagheid dan ook niet.

                    Musl is nu mede de basis voor Alpine Linux. Leuk systeempje, maar het heeft in de plaats van apt of apt-get van Debian/Ubuntu/Mint iets anders, dat ook goed werkt, maar niet compatibel is. Mijn nu geheel automatische website-installateur (niet open-source, want specifiek voor mijn site, niet generiek) heb ik er nog niet naar geporteerd.

                    1. Kortom, ik ben het met Wim ten Brink eens (als ik zijn standpunt zo samen mag vatten, anders hoor ik het wel): als je techneut bent, zeeën van tijd hebt om dingen uit te zoeken, en weinig harde deadlines, dan valt er met gratis FOSS (free open source software; free slaat daarin op de vrijheid het te gebruiken en eventueel te bewerken; gratis hoeft het niet per se te zijn) prima te werken.

                      Maar heb je zelf weinig sjoege van programmeren, installeren en configureren, of heb je veel klanten en weinig tijd of personeel, en moet het gewoon werken, dan kun je beter betalen voor ondersteuning door een commercieel bedrijf. Dat kan Microsoft zijn, of RedHat/IBM, of Canonical. Suse is ook commercieel, las ik laatst ergens.

                      Maar dan nog weet je niet zeker dat je nooit gedonderjaag krijgt. Maar ja, in dit leven is sowieso niets zeker. Behalve dat we uiteindelijk allemaal dood gaan. Maar voorlopig nog even niet, hoop ik toch en wens ik iedereen toe.

                      1. In Debian 10 en 11 (9 ook?) staat de component binutils (nodig in elke compileeromgeving) te boek als onbetrouwbaar. Bij installeren krijg je een waarschuwingsscherm waar lastig uit te komen is. Mijn als unattended bedoelde installatiescript (bedoeld om t.z.t. ook door niet al te technische nazaten te kunnen worden gedraaid) liep erop vast.

                        Of kwam dat vastlopen door een bug in mijn eigen script? Ik weet het niet meer. Anyway, ik heb nu een versie die het doet onder Debian 9, 10, 11 en Ubuntu Server 18.04, 20.04 en 21.04, en Raspberry OS (voor Intel) en Bodhi Linux.

                        Het Debian-probleem was al in 2019 bekend, bleek uit discussies die ik las, en stelt waarschijnlijk niks voor. Een paar eigenwijze ontwikkelaars en beheerders willen allebei niet de nodige stappen zetten en verantwoordelijkheid nemen, of zo iets. Maar anno januari 2022 is het nog steeds niet gefixt, het zit gewoon nog in de nieuwste Debian 11. Niet in Ubuntu lijkt het. Canonical heeft er wel iets aan gedaan? Want die zijn commercieel en hebben klagende klanten.

                        Maar dit ondermijnde wel mijn vertrouwen in FOSS met alleen support door “the community”. Als daar een paar eikels op de verkeerde plek tussen zitten, heb je toch wel problemen. In theorie kun je alles zelf fixen, maar ga daar maar eens induiken. Andermans code doorzien is echt niet altijd makkelijk.

                      2. Wow. Kon dat niet allemaal in 1 post? 😀

                        Betreffende FOSS tegen commercie… Waar ik vooral op doel is dat als je een commercieel bedrijf op een bug aanspreekt die mogelijk schade kan opleveren, dan zouden ze dat in principe zo snel mogelijk moeten oplossen. Als ze dit verzuimen dan kunnen ze mogelijk opdraaien voor gevolgschade.

                        Maar als je een bug in FOSS meldt dan kan de ontwikkelaar dat gewoon negeren en zeggen dat je het zelf maar oplost. Hij heeft er even geen zin in. Is met vakantie. Is met iets anders bezig. Of heeft helemaal geen zin meer in het project. Je krijgt dan eigenlijk een project onder beheer van iemand die niet gemotiveerd is om er verder mee te gaan, maar wat ook niet makkelijk overgenomen kan worden door anderen, tenzij conform de licentievoorwaarden. Waarbij je ook rekening mee moet houden dat je wel een branch kunt maken van het project, maar niet de naam ervan kan blijven gebruiken want dat is een handelsmerk!

                        Je hebt bij FOSS dus geen dwangmiddelen om de makers ervan te dwingen om de bugs te repareren. Commerciële bedrijven zijn beter gemotiveerd in het algemeen.

    2. Zo maak ik mij bijvoorbeeld bij web development zorgen om de toenemende populariteit van web frameworks

      Ik ook. Wat de slimme veiligheidsdiensten doen: alle populaire open-source software downloaden en de meest geavanceerde veiligheidsbugs worden automatisch gevonden. Ze weten dan precies hoe ze gemakkelijk binnen kunnen komen, bij zeg, Alibaba Cloud. En dan hebben ze ook nog controle over Anaconda, en iedereen herinstalleert alles vanaf een text-bestand zonder ernaar te kijken. Hebben ze alleen je IP nodig voor een extra-gratis speciale update. En anders krijgen ze wel admin op een populair project, door veel bug-fixes en documentatie bij te dragen. Hebben ze controle over de keuze van de random nummer generator. Of betalen ze een Roemeen met een populaire browser-extensie 2000 dollar per maand voor toegang tot de gebruikersgegevens.

      Ikzelf denk dat de log4j vulnerability nooit door criminelen in het wild is gebruikt. China kwam erachter en trok meteen aan de bel. Dat was de paniek.

  5. Ik weet niet precies welke software van Daniel Stenberg door het onbekende bedrijf gebruikt wordt, maar een snelle scan van de cURL broncode doet me vermoeden dat “we zien de log4j bug niet als probleem” het antwoord is voor de bezitters van een onderhoudscontract. Log4j wordt namelijk niet gebruikt in C programma’s.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.