Libxml2-maintainer gaat gemelde kwetsbaarheden meteen openbaar maken
De lead maintainer van libxml2, een library voor het verwerken van xml-documenten, gaat kwetsbaarheden die bij het project worden gemeld meteen openbaar maken, ook als er nog geen oplossing voor is. Beveiligingslekken worden verholpen wanneer maintainers hiervoor de tijd hebben, er zullen geen deadlines meer zijn. "Dit beleid zal sommige downstream-gebruikers zenuwachtig maken, maar het zal ze misschien aanmoedigen om meer bij te dragen", aldus Nick Wellnhofer. Verschillende browsers en besturingssystemen maken gebruik van libxml2.
Wellnhofer stelt dat hij meerdere uren per week bezig is met beveiligingsproblemen die door derde partijen worden gemeld. "De meeste van deze problemen zijn niet kritiek, maar nog steeds wel veel werk. Op de lange termijn is het onhoudbaar voor een onbetaalde vrijwilliger als ik." Als oplossing wil Wellnhofer daarom een nieuw beleid met betrekking tot het openbaar maken. Op dit moment geldt er nog een embargo van kwetsbaarheden waarvoor nog geen patch beschikbaar is.
"Ik doe dit al lang genoeg om te weten dat de meeste geheimzinnigheid rond beveiligingsproblemen juist theater is", aldus Wellnhofer. "Alle "best practices" zoals OpenSSF Scorecards zijn gewoon een poging van bigtechbedrijven om OSS maintainers een schuld gevoel te geven en ze gratis te laten werken." Volgens Wellnhofer is het nadelig om dit soort eisen aan maintainers van opensourceprojecten te stellen, zonder dat ze hiervoor worden gecompenseerd.
"Ongeschikt voor gebruik"
Daarnaast stelt Wellnhofer dat libxml2 nooit de kwaliteit heeft gehad om in mainstream browsers en besturingssystemen gebruikt te worden. "Het begon toen Apple libxml2 een kernonderdeel van al hun besturingssystemen maakte. Toen volgde Google en nu gebruikt zelf Microsoft libxml2 in hun besturingssysteem buiten Edge. Dit had nooit moeten plaatsvinden, merkt de lead maintainer op.Oorspronkelijk was het volgens Wellnhofer een soort van 'growth hack'. "Maar nu maken die bedrijven miljarden winst en weigeren hun technische schuld terug te betalen, door naar betere oplossingen over te stappen, hun eigen oplossing te ontwikkelen of te proberen om libxml2 te verbeteren." Volgens Wellnhofer is het gedrag van deze bedrijven onverantwoord. De lead maintainer voegt toe dat hij beveiligingsproblemen niet langer onder embargo zal houden totdat een oplossing beschikbaar is.
Update
Inmiddels is Wellnhofer ook begonnen om van verschillende kwetsbaarheden de details openbaar te maken. "Removing confidentiality as per our new policy", laat de maintainer onder de openbaar gemaakte kwetsbaarheden weten.Reacties (24)
23-06-2025, 12:36 door
Anoniem
Toch mooi, dat voor dit soort libraries die zo veel gebruikt wordt, er dus eigenlijk zoveel werk is aan security reports, dat dit door vrijwilligers niet vol te houden is.
Ik zie een groot risico bij het gebruik van dit soort libraries.
Ik zie een groot risico bij het gebruik van dit soort libraries.
23-06-2025, 12:58 door
dingetje
"I'm thinking about adding the following disclaimer:
This is open-source software written by hobbyists, maintained by a single volunteer, badly tested, written in a memory-unsafe language and full of security bugs. It is foolish to use this software to process untrusted data. As such, we treat security issues like any other bug. Each security report we receive will be made public immediately and won't be prioritized."
Van mij had 'open-source' wel weggelaten kunnen worden. Het probleem is niet direct gerelateerd aan juridische aspecten van een licentie, maar aan eenzijdig winstbejag zonder tegeninvestering in het ecosysteem. Er wordt wel meer software onder de MIT-licentie* gepubliceerd waarvoor genoemde problemen niet gelden.
* https://en.wikipedia.org/wiki/Libxml2
This is open-source software written by hobbyists, maintained by a single volunteer, badly tested, written in a memory-unsafe language and full of security bugs. It is foolish to use this software to process untrusted data. As such, we treat security issues like any other bug. Each security report we receive will be made public immediately and won't be prioritized."
Van mij had 'open-source' wel weggelaten kunnen worden. Het probleem is niet direct gerelateerd aan juridische aspecten van een licentie, maar aan eenzijdig winstbejag zonder tegeninvestering in het ecosysteem. Er wordt wel meer software onder de MIT-licentie* gepubliceerd waarvoor genoemde problemen niet gelden.
* https://en.wikipedia.org/wiki/Libxml2
23-06-2025, 12:58 door
Anoniem
Na het bericht te hebben gelezen snap ik de beste man wel eigenlijk...
23-06-2025, 13:24 door
Anoniem
Deze voelt weer eens erg relevant: https://xkcd.com/2347/
23-06-2025, 13:37 door
Anoniem
libxml2 heeft nl wel heel veel kwetsbaarheden, bedrijven die deze component gebruiken worden straks helemaal simpel als de CRA geldig wordt
23-06-2025, 14:01 door
Anoniem
Het is gewoon komkommercialisme... graaien wat je graaien kan, en binnenharken waar je mee weg kunt komen.
Welkom in de wereld van Amerika.
Nummer 2 is de eerste verliezer, collectieve ziektenkosten verzekeringen is voor loosers en communisten.. iedereen moet aan de democratie, desnoods met bommen, een door de CIA geinstigeerde 'lente'...
Dat die democratie niet eens een democratie is, boeie...
Maar vervolgens moet je wel aan het cola, disney en cisco infuus... of je tegen spuitjes kan of niet..
Of je moet tegen de VS durven zeggen, 'tot hier en niet verder'... maar ik denk niet dat iemand tegen de club van 'do as I say, not as I do' in durft te gaan.
Welkom in de wereld van Amerika.
Nummer 2 is de eerste verliezer, collectieve ziektenkosten verzekeringen is voor loosers en communisten.. iedereen moet aan de democratie, desnoods met bommen, een door de CIA geinstigeerde 'lente'...
Dat die democratie niet eens een democratie is, boeie...
Maar vervolgens moet je wel aan het cola, disney en cisco infuus... of je tegen spuitjes kan of niet..
Of je moet tegen de VS durven zeggen, 'tot hier en niet verder'... maar ik denk niet dat iemand tegen de club van 'do as I say, not as I do' in durft te gaan.
23-06-2025, 14:15 door
Anoniem
Door dingetje: Van mij had 'open-source' wel weggelaten kunnen worden. Het probleem is niet direct gerelateerd aan juridische aspecten van een licentie, maar aan eenzijdig winstbejag zonder tegeninvestering in het ecosysteem. Er wordt wel meer software onder de MIT-licentie* gepubliceerd waarvoor genoemde problemen niet gelden.
Nick Wellnhofer legt het verband zelf wel: In the long run, putting such demands on OSS maintainers without compensating them is detrimental.
En dit winstbejag zonder tegeninvestering in het ecosysteem, zoals jij het verwoordt, kan natuurlijk alleen maar bij dit soort licenties. Als het een commerciële library was geweest had Apple, Google of Microsoft het bedrijfje waarschijnlijk allang overgenomen voor een smak geld waarvan Wellnhofer desgewenst had kunnen gaan rentenieren, was het intern bij ze verder ontwikkeld met net zoveel FTE's erop als het nodig heeft, en hadden de twee andere tech-reuzen het niet kunnen gebruiken en dus iets anders moeten overnemen of zelf ontwikkelen.Het hele punt van open source is dat je dat soort dubbel werk voorkomt, en dat het model goed werkt als zelfs maar een bescheiden deel van de gebruikers een maar bescheiden bijdrage levert. Als deze giganten van gebruikers er elk ook maar een handjevol mensuren per week aan zouden besteden zou het voor dat project een enorme boost zijn, zou iedereen een betere library hebben, terwijl voor die enorme reuzen het verschil in inspanning amper waarneembaar zou zijn op alles wat ze doen. En toch doen ze het kennelijk niet, terwijl de enorme schaal waarop juist zij het gebruiken wel een grote druk op de ontwikkelaar oplevert.
Dat is parasitair omgaan met iets moois, en dat mag best hardop worden gezegd. Inclusief dat het open source betreft, want daarop wordt hier geparasiteerd door Apple, Google en Microsoft.
23-06-2025, 14:31 door
Anoniem
Door Anoniem: Het is gewoon komkommercialisme... graaien wat je graaien kan, en binnenharken waar je mee weg kunt komen.
Welkom in de wereld van Amerika.
Nummer 2 is de eerste verliezer, collectieve ziektenkosten verzekeringen is voor loosers en communisten.. iedereen moet aan de democratie, desnoods met bommen, een door de CIA geinstigeerde 'lente'...
Dat die democratie niet eens een democratie is, boeie...
Maar vervolgens moet je wel aan het cola, disney en cisco infuus... of je tegen spuitjes kan of niet..
Of je moet tegen de VS durven zeggen, 'tot hier en niet verder'... maar ik denk niet dat iemand tegen de club van 'do as I say, not as I do' in durft te gaan.
Welkom in de wereld van Amerika.
Nummer 2 is de eerste verliezer, collectieve ziektenkosten verzekeringen is voor loosers en communisten.. iedereen moet aan de democratie, desnoods met bommen, een door de CIA geinstigeerde 'lente'...
Dat die democratie niet eens een democratie is, boeie...
Maar vervolgens moet je wel aan het cola, disney en cisco infuus... of je tegen spuitjes kan of niet..
Of je moet tegen de VS durven zeggen, 'tot hier en niet verder'... maar ik denk niet dat iemand tegen de club van 'do as I say, not as I do' in durft te gaan.
Grote bla bla, maar nul oplossing.
ff kijken : hobby project .
Wordt populair (mooi toch, roepen "we" altijd dat we dat willen ).
Blijkt het opeens toch bugs te hebben - wat alleen maar opvalt omdat het aandacht krijgt vanwege de populariteit.
En dan deugt dat weer niet . Ja joh, het is ook nooit goed.
Vertel eens, hoeveer trek jij je eigen portemonnee open voor open source projecten ?
of sta je alleen maar aan de zijkant te roepen dat open source zo geweldig is, en als het niet geweldig is moet iemand anders het oplossen ?
Mogen een paar van die 'many eyes' waarvoor all bugs shallow zijn zich even melden ? Of gewoon lappen ?
23-06-2025, 14:32 door
Anoniem
Bedrijven die gebruik maken van deze library zouden eigenlijk moeten betalen met geld of mankracht om dit project draaiende te houden
23-06-2025, 16:45 door
_R0N_
Door Anoniem:
Vertel eens, hoeveer trek jij je eigen portemonnee open voor open source projecten ?
Vertel eens, hoeveer trek jij je eigen portemonnee open voor open source projecten ?
Dat is natuurlijk het hele probleem en dat zie je hier vaak genoeg voorbij komen. Hoevele mensen roepen wel niet dat je maar Open Source moet gebruiken wanneer er bij een Closed Source product een lek gevonden wordt.
Het argument van "iedereen kan de code bekijken en fixen" is alleen op papier zo. Degene die het bekijken doen het om lekken te vinden en te misbruiken en de rest verwacht van de maintainer dat hij (of zij) het oplost zonder zelf ook maar een bijdrage te doen.
23-06-2025, 16:45 door
_R0N_
Door Anoniem: Bedrijven die gebruik maken van deze library zouden eigenlijk moeten betalen met geld of mankracht om dit project draaiende te houden
Bedrijven die het gebruiken doen dat omdat het gratis is.
23-06-2025, 19:32 door
Anoniem
Grote bla bla, maar nul oplossing.
ff kijken : hobby project .
Wordt populair (mooi toch, roepen "we" altijd dat we dat willen ).
Blijkt het opeens toch bugs te hebben - wat alleen maar opvalt omdat het aandacht krijgt vanwege de populariteit.
En dan deugt dat weer niet . Ja joh, het is ook nooit goed.
Vertel eens, hoeveer trek jij je eigen portemonnee open voor open source projecten ?
of sta je alleen maar aan de zijkant te roepen dat open source zo geweldig is, en als het niet geweldig is moet iemand anders het oplossen ?
Mogen een paar van die 'many eyes' waarvoor all bugs shallow zijn zich even melden ? Of gewoon lappen ?
Wat een monsterlijk voorbeeld van whataboutism. Ik verdien geen 95 miljard met freeloading op bsd en dit soort ontwikkelaars, waarom zou dat okay zijn als ik niets zou doen? Bovendien ben ik al 20 jaar sponsor van nluug, dus FU.
23-06-2025, 20:59 door
Anoniem
Door Anoniem:
Grote bla bla, maar nul oplossing.
ff kijken : hobby project .
Wordt populair (mooi toch, roepen "we" altijd dat we dat willen ).
Blijkt het opeens toch bugs te hebben - wat alleen maar opvalt omdat het aandacht krijgt vanwege de populariteit.
En dan deugt dat weer niet . Ja joh, het is ook nooit goed.
Vertel eens, hoeveer trek jij je eigen portemonnee open voor open source projecten ?
of sta je alleen maar aan de zijkant te roepen dat open source zo geweldig is, en als het niet geweldig is moet iemand anders het oplossen ?
Mogen een paar van die 'many eyes' waarvoor all bugs shallow zijn zich even melden ? Of gewoon lappen ?
Wat een monsterlijk voorbeeld van whataboutism. Ik verdien geen 95 miljard met freeloading op bsd en dit soort ontwikkelaars, waarom zou dat okay zijn als ik niets zou doen? Bovendien ben ik al 20 jaar sponsor van nluug, dus FU.
Grote bla bla, maar nul oplossing.
ff kijken : hobby project .
Wordt populair (mooi toch, roepen "we" altijd dat we dat willen ).
Blijkt het opeens toch bugs te hebben - wat alleen maar opvalt omdat het aandacht krijgt vanwege de populariteit.
En dan deugt dat weer niet . Ja joh, het is ook nooit goed.
Vertel eens, hoeveer trek jij je eigen portemonnee open voor open source projecten ?
of sta je alleen maar aan de zijkant te roepen dat open source zo geweldig is, en als het niet geweldig is moet iemand anders het oplossen ?
Mogen een paar van die 'many eyes' waarvoor all bugs shallow zijn zich even melden ? Of gewoon lappen ?
Wat een monsterlijk voorbeeld van whataboutism. Ik verdien geen 95 miljard met freeloading op bsd en dit soort ontwikkelaars, waarom zou dat okay zijn als ik niets zou doen? Bovendien ben ik al 20 jaar sponsor van nluug, dus FU.
Dan ben je één van de weinigen die een beetje lapt voor het ene of andere OS project.
(ik ook, trouwens.).
Ik zie wel eens hoe ONTZETTEND WEINIG er aan donaties binnenkomt bij 'geek-causes' , en wat een enorm grote bek mensen erover hebben . Of $2.50 doneren en dan EISEN dat hun wishlist feature meteen opgepakt wordt.
23-06-2025, 21:11 door
Anoniem
Door _R0N_:
Bedrijven die het gebruiken doen dat omdat het gratis is.
Door Anoniem: Bedrijven die gebruik maken van deze library zouden eigenlijk moeten betalen met geld of mankracht om dit project draaiende te houden
Bedrijven die het gebruiken doen dat omdat het gratis is.
Misschien niet eens dat.
Vermoedelijk (vooral) omdat de developers binnen die bedrijven bekend zijn met de code - en het zichzelf makkelijk maken zonder een heel intern circus in te gaan.
Ik _denk_ dat het voor developers best een hoop "intern gedoe" is om het gebruik van commerciele library geregeld te krijgen. Aanvraag, approval, legal, procurement die namens "google" of "apple" even een mega licentie moet onderhandelen .
Als de developer eerst moet beginnen met de formele aanvraag van een trial licentie om zelfs maar te kijken of iets geschik is -
Nogal wat ITers zijn niet sterk in het "interne procesgedoe" , en willen vooral doorgaan met coden.
Dan zal het vrij snel zijn dat de developer kiest voor een library die "bekend/inzichtelijk" is, zelfs als die niet technisch de beste keuze is .
24-06-2025, 01:27 door
Anoniem
Door Anoniem:
Misschien niet eens dat.
Vermoedelijk (vooral) omdat de developers binnen die bedrijven bekend zijn met de code - en het zichzelf makkelijk maken zonder een heel intern circus in te gaan.
Ik _denk_ dat het voor developers best een hoop "intern gedoe" is om het gebruik van commerciele library geregeld te krijgen. Aanvraag, approval, legal, procurement die namens "google" of "apple" even een mega licentie moet onderhandelen .
Als de developer eerst moet beginnen met de formele aanvraag van een trial licentie om zelfs maar te kijken of iets geschik is -
Nogal wat ITers zijn niet sterk in het "interne procesgedoe" , en willen vooral doorgaan met coden.
Dan zal het vrij snel zijn dat de developer kiest voor een library die "bekend/inzichtelijk" is, zelfs als die niet technisch de beste keuze is .
Helaas bevatten de betaalde oplossingen nog veel meer kwetsbaarheden, echter zijn deze niet door Jan en alleman te vinden maar puur door de echte boeven.Door _R0N_:
Bedrijven die het gebruiken doen dat omdat het gratis is.
Door Anoniem: Bedrijven die gebruik maken van deze library zouden eigenlijk moeten betalen met geld of mankracht om dit project draaiende te houden
Bedrijven die het gebruiken doen dat omdat het gratis is.
Misschien niet eens dat.
Vermoedelijk (vooral) omdat de developers binnen die bedrijven bekend zijn met de code - en het zichzelf makkelijk maken zonder een heel intern circus in te gaan.
Ik _denk_ dat het voor developers best een hoop "intern gedoe" is om het gebruik van commerciele library geregeld te krijgen. Aanvraag, approval, legal, procurement die namens "google" of "apple" even een mega licentie moet onderhandelen .
Als de developer eerst moet beginnen met de formele aanvraag van een trial licentie om zelfs maar te kijken of iets geschik is -
Nogal wat ITers zijn niet sterk in het "interne procesgedoe" , en willen vooral doorgaan met coden.
Dan zal het vrij snel zijn dat de developer kiest voor een library die "bekend/inzichtelijk" is, zelfs als die niet technisch de beste keuze is .
Juist omdat iets betaald is hoeft het niet kwalitatief te zijn
Ik ben het er mee eens* dat het voor programmeurs aantrekkelijk is om zo'n project te gebruiken, voor bedrijven omdat ze er niet voor hoeven te betalen. Dat mag, en kan een aspect zijn van FLOSS.
En bedrijven gebruiken soms ook hele stukken code (tegenwoordig al dan niet via AI) waarvan de auteur en licentie niet eens worden genoemd.
Het is gemak en onkunde als een bedrijf niet de juiste security audits laat uitvoeren, dat het geen patches maakt en dat het die patches ook niet beschikbaar stelt voor de oorspronkelijke auteur van wie ze de code proletarisch hebben geleend.
Maar nogmaals, dat staat allemaal los van de licentie. Het maakt niet uit of je dezelfde software in gebruik hebt onder een open source licentie of een commerciële licentie. Software kan net zo makkelijk onder een duale licentie worden uitgebracht. Een licentie is iets juridisch, dat zegt niets over de kwaliteit van code. Bijvoorbeeld webkit en android zijn ook OSS, en dat wordt ook zonder al te veel ophef door de massa gebruikt.
Waar het om gaat is dat een bedrijf een project van iemand anders gebruikt, en wanneer het misgaat kijken ze niet naar hun eigen professionaliteit maar wijzen ze naar diegene waarvan ze (zonder tegenprestatie) code hebben afgenomen. In het geval van libxml2 is die persoon ook niet gek en waarschuwt nu vooraf dat hij die verantwoordelijkheid niet gaat nemen, hij legt de verantwoordelijkheid over security gewoon terug bij degene die zijn code gebruikt. Dat is een stapje verder dan dat maintainers normaal gesproken doen, maar ik zou hetzelfde gedaan kunnen hebben onder druk van dergelijke 'bedrijvigheid'.
* ook de 2e reactie op https://www.security.nl/posting/893337/Full+disclosure+van+kwetsbaarheden+in+libxml2%3A#replies
En bedrijven gebruiken soms ook hele stukken code (tegenwoordig al dan niet via AI) waarvan de auteur en licentie niet eens worden genoemd.
Het is gemak en onkunde als een bedrijf niet de juiste security audits laat uitvoeren, dat het geen patches maakt en dat het die patches ook niet beschikbaar stelt voor de oorspronkelijke auteur van wie ze de code proletarisch hebben geleend.
Maar nogmaals, dat staat allemaal los van de licentie. Het maakt niet uit of je dezelfde software in gebruik hebt onder een open source licentie of een commerciële licentie. Software kan net zo makkelijk onder een duale licentie worden uitgebracht. Een licentie is iets juridisch, dat zegt niets over de kwaliteit van code. Bijvoorbeeld webkit en android zijn ook OSS, en dat wordt ook zonder al te veel ophef door de massa gebruikt.
Waar het om gaat is dat een bedrijf een project van iemand anders gebruikt, en wanneer het misgaat kijken ze niet naar hun eigen professionaliteit maar wijzen ze naar diegene waarvan ze (zonder tegenprestatie) code hebben afgenomen. In het geval van libxml2 is die persoon ook niet gek en waarschuwt nu vooraf dat hij die verantwoordelijkheid niet gaat nemen, hij legt de verantwoordelijkheid over security gewoon terug bij degene die zijn code gebruikt. Dat is een stapje verder dan dat maintainers normaal gesproken doen, maar ik zou hetzelfde gedaan kunnen hebben onder druk van dergelijke 'bedrijvigheid'.
* ook de 2e reactie op https://www.security.nl/posting/893337/Full+disclosure+van+kwetsbaarheden+in+libxml2%3A#replies
24-06-2025, 09:16 door
Anoniem
Had ooit een collega die een stuk software open source had gemaakt, en vroeg een vrijwillige bijdrage van een hele dollar. Nou toch niet echt een bedrag waaraan je failliet gaat om dat te doneren. De collega kreeg in de loop der jaren welgeteld precies EEN (1) dollar (biljet per post opgestuurd), dat was alles.
24-06-2025, 09:34 door
_R0N_
Door Anoniem:
Helaas bevatten de betaalde oplossingen nog veel meer kwetsbaarheden, echter zijn deze niet door Jan en alleman te vinden maar puur door de echte boeven.
Juist omdat iets betaald is hoeft het niet kwalitatief te zijn
Helaas bevatten de betaalde oplossingen nog veel meer kwetsbaarheden, echter zijn deze niet door Jan en alleman te vinden maar puur door de echte boeven.
Juist omdat iets betaald is hoeft het niet kwalitatief te zijn
Dat is een aanname op niets gebaseerd natuurlijk en dat weet je zelf ook.
Het voordeel van betaalde software is dat er ook budget is om problemen op te lossen.
Ook bij software krijg je waar je voor betaalt.
24-06-2025, 09:37 door
_R0N_
Door Anoniem:
Misschien niet eens dat.
Vermoedelijk (vooral) omdat de developers binnen die bedrijven bekend zijn met de code - en het zichzelf makkelijk maken zonder een heel intern circus in te gaan.
Ik _denk_ dat het voor developers best een hoop "intern gedoe" is om het gebruik van commerciele library geregeld te krijgen. Aanvraag, approval, legal, procurement die namens "google" of "apple" even een mega licentie moet onderhandelen .
Als de developer eerst moet beginnen met de formele aanvraag van een trial licentie om zelfs maar te kijken of iets geschik is -
Nogal wat ITers zijn niet sterk in het "interne procesgedoe" , en willen vooral doorgaan met coden.
Dan zal het vrij snel zijn dat de developer kiest voor een library die "bekend/inzichtelijk" is, zelfs als die niet technisch de beste keuze is .
Door _R0N_:
Bedrijven die het gebruiken doen dat omdat het gratis is.
Door Anoniem: Bedrijven die gebruik maken van deze library zouden eigenlijk moeten betalen met geld of mankracht om dit project draaiende te houden
Bedrijven die het gebruiken doen dat omdat het gratis is.
Misschien niet eens dat.
Vermoedelijk (vooral) omdat de developers binnen die bedrijven bekend zijn met de code - en het zichzelf makkelijk maken zonder een heel intern circus in te gaan.
Ik _denk_ dat het voor developers best een hoop "intern gedoe" is om het gebruik van commerciele library geregeld te krijgen. Aanvraag, approval, legal, procurement die namens "google" of "apple" even een mega licentie moet onderhandelen .
Als de developer eerst moet beginnen met de formele aanvraag van een trial licentie om zelfs maar te kijken of iets geschik is -
Nogal wat ITers zijn niet sterk in het "interne procesgedoe" , en willen vooral doorgaan met coden.
Dan zal het vrij snel zijn dat de developer kiest voor een library die "bekend/inzichtelijk" is, zelfs als die niet technisch de beste keuze is .
Voor veel bedrijven is het ook een kwestie van "indekken". Als je software koopt zit daar een bepaalde waarborging op en een service verwachting. Een commercieel bedrijf kan niet goed tegen imago schade en dus zal eerder moeite doen om software te onderhouden.
Een plotseling populair stuk software van een eenpitter dat hij op z'n zolderkamer geschreven heeft geeft geen enkele garantie. Als de ontwikkelaar geen zin meer heeft of geen tijd heeft blijft het gewoon best effort.
24-06-2025, 10:22 door
antipanda
Op zich wel een slimme tacktiek van deze open source ontwikkelaar. Als de software van iedereen is, is het probleem ook van iedereen.
Zou het een idee zijn dat problemen met open source software een openbare aanbesteding krijgen waarbij belanghebbenden geld kunnen storten om een bepaald probleem op te lossen, tot er voldoende budget is voor een programmeur om het probleem te fixen.
Open source hoeft niet noodzakelijk te betekenen dat programmeurs niet betaald worden. Ze moeten alleen betaald worden voor het werk wat ze doen en niet voor de licentie om de software te gebruiken.
Zou het een idee zijn dat problemen met open source software een openbare aanbesteding krijgen waarbij belanghebbenden geld kunnen storten om een bepaald probleem op te lossen, tot er voldoende budget is voor een programmeur om het probleem te fixen.
Open source hoeft niet noodzakelijk te betekenen dat programmeurs niet betaald worden. Ze moeten alleen betaald worden voor het werk wat ze doen en niet voor de licentie om de software te gebruiken.
24-06-2025, 10:26 door
Anoniem
Door Anoniem: Had ooit een collega die een stuk software open source had gemaakt, en vroeg een vrijwillige bijdrage van een hele dollar. Nou toch niet echt een bedrag waaraan je failliet gaat om dat te doneren. De collega kreeg in de loop der jaren welgeteld precies EEN (1) dollar (biljet per post opgestuurd), dat was alles.
Verbaasd me helemaal niks.
De "open source community" staat vooral achter je met roepen op fora. Maar putting money where their mouth is , nope.
24-06-2025, 10:49 door
Anoniem
Door _R0N_:
Voor veel bedrijven is het ook een kwestie van "indekken". Als je software koopt zit daar een bepaalde waarborging op en een service verwachting. Een commercieel bedrijf kan niet goed tegen imago schade en dus zal eerder moeite doen om software te onderhouden.
Een plotseling populair stuk software van een eenpitter dat hij op z'n zolderkamer geschreven heeft geeft geen enkele garantie. Als de ontwikkelaar geen zin meer heeft of geen tijd heeft blijft het gewoon best effort.
Door Anoniem:
Misschien niet eens dat.
Vermoedelijk (vooral) omdat de developers binnen die bedrijven bekend zijn met de code - en het zichzelf makkelijk maken zonder een heel intern circus in te gaan.
Ik _denk_ dat het voor developers best een hoop "intern gedoe" is om het gebruik van commerciele library geregeld te krijgen. Aanvraag, approval, legal, procurement die namens "google" of "apple" even een mega licentie moet onderhandelen .
Als de developer eerst moet beginnen met de formele aanvraag van een trial licentie om zelfs maar te kijken of iets geschik is -
Nogal wat ITers zijn niet sterk in het "interne procesgedoe" , en willen vooral doorgaan met coden.
Dan zal het vrij snel zijn dat de developer kiest voor een library die "bekend/inzichtelijk" is, zelfs als die niet technisch de beste keuze is .
Door _R0N_:
Bedrijven die het gebruiken doen dat omdat het gratis is.
Door Anoniem: Bedrijven die gebruik maken van deze library zouden eigenlijk moeten betalen met geld of mankracht om dit project draaiende te houden
Bedrijven die het gebruiken doen dat omdat het gratis is.
Misschien niet eens dat.
Vermoedelijk (vooral) omdat de developers binnen die bedrijven bekend zijn met de code - en het zichzelf makkelijk maken zonder een heel intern circus in te gaan.
Ik _denk_ dat het voor developers best een hoop "intern gedoe" is om het gebruik van commerciele library geregeld te krijgen. Aanvraag, approval, legal, procurement die namens "google" of "apple" even een mega licentie moet onderhandelen .
Als de developer eerst moet beginnen met de formele aanvraag van een trial licentie om zelfs maar te kijken of iets geschik is -
Nogal wat ITers zijn niet sterk in het "interne procesgedoe" , en willen vooral doorgaan met coden.
Dan zal het vrij snel zijn dat de developer kiest voor een library die "bekend/inzichtelijk" is, zelfs als die niet technisch de beste keuze is .
Voor veel bedrijven is het ook een kwestie van "indekken". Als je software koopt zit daar een bepaalde waarborging op en een service verwachting. Een commercieel bedrijf kan niet goed tegen imago schade en dus zal eerder moeite doen om software te onderhouden.
Een plotseling populair stuk software van een eenpitter dat hij op z'n zolderkamer geschreven heeft geeft geen enkele garantie. Als de ontwikkelaar geen zin meer heeft of geen tijd heeft blijft het gewoon best effort.
Je spreekt jezelf daar tegen.
Als een Google of een Apple of Redhat of Debian ervoor kiest om een open source library te gebruiken , is het wel (ook) hun probleem als daar bugs in zitten.
Niks doen en wijzen naar een eenpitter-upstream helpt dan niet .
Als wachten op een "urgente want security" fix van "upstream supplier" niet werkt is het alternatief zelf een workaround of mitigation schrijven (mooi toch, open source) - en dan wachten op de 'nette definitieve fix' van "upstream" .
Prima gedachte .
Alleen hier is 'upstream' dus een eenpitter die het niet meer trekt .
Maar deze vendoren "kiezen" toch voor modules met garantie tot de download , waar niks in te dekken is - en ik denk dat dat gedreven is door de interne ontwikkelaars die 'gewoon willen doorgaan' en dan een open source library kiezen die ze kennen , en geen aanvraag traject ingaan voor een commerciele versie .
Of geen project (kunnen) laten starten om iets in-house te laten ontwikkelen .
Het is niet dat "het megabedrijf" daar geen geld voor heeft , het is dat het development team dat gewoon 'iets moet bouwen' zo'n eigen ontwikkelde library niet snel van de grond krijgt als het niet Heel Erg Nodig is .
24-06-2025, 11:32 door
Anoniem
Door _R0N_:
Dat is een aanname op niets gebaseerd natuurlijk en dat weet je zelf ook.
Het voordeel van betaalde software is dat er ook budget is om problemen op te lossen.
Ook bij software krijg je waar je voor betaalt.
Het is ook een verkeerde aanname dat omdat software closed source of betaald is dat deze dan automatisch van hogere kwaliteit zou zijn of dat er budget is om security problemen op te lossen. Door Anoniem:
Helaas bevatten de betaalde oplossingen nog veel meer kwetsbaarheden, echter zijn deze niet door Jan en alleman te vinden maar puur door de echte boeven.
Juist omdat iets betaald is hoeft het niet kwalitatief te zijn
Helaas bevatten de betaalde oplossingen nog veel meer kwetsbaarheden, echter zijn deze niet door Jan en alleman te vinden maar puur door de echte boeven.
Juist omdat iets betaald is hoeft het niet kwalitatief te zijn
Dat is een aanname op niets gebaseerd natuurlijk en dat weet je zelf ook.
Het voordeel van betaalde software is dat er ook budget is om problemen op te lossen.
Ook bij software krijg je waar je voor betaalt.
Het is namelijk juist bij gesloten software minder te bewijzen
26-06-2025, 16:51 door
Anoniem
Door _R0N_:
Dat is een aanname op niets gebaseerd natuurlijk en dat weet je zelf ook.
Het voordeel van betaalde software is dat er ook budget is om problemen op te lossen.
Ook bij software krijg je waar je voor betaalt.
Tenminste zolang het bedrijf niet failliet gaat of een versie 2 maakt en je 'mag' upgraden aan 75% van de nieuwprijs of het stuk software ineens obsolete maakt want te duur om te onderhouden.Door Anoniem:
Helaas bevatten de betaalde oplossingen nog veel meer kwetsbaarheden, echter zijn deze niet door Jan en alleman te vinden maar puur door de echte boeven.
Juist omdat iets betaald is hoeft het niet kwalitatief te zijn
Helaas bevatten de betaalde oplossingen nog veel meer kwetsbaarheden, echter zijn deze niet door Jan en alleman te vinden maar puur door de echte boeven.
Juist omdat iets betaald is hoeft het niet kwalitatief te zijn
Dat is een aanname op niets gebaseerd natuurlijk en dat weet je zelf ook.
Het voordeel van betaalde software is dat er ook budget is om problemen op te lossen.
Ook bij software krijg je waar je voor betaalt.
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
Cybersecurity Trainer / Full Stack Developer
Ben je toe aan een nieuwe job waarmee je het verschil maakt? Wil jij je security kennis graag delen en hands-on laten zien hoe cybersecurity in de praktijk echt werkt? Werk je net als wij graag samen met enthousiaste en gedreven collega's? Bij ons geen bureaucratie maar open communicatie en een werkomgeving gericht op samenwerking.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?