Google gaat veiligheidspatches voor opensource-software belonen

Google looft beloningen tussen de 500 en 3133,70 dollar uit voor ontwikkelaars die patches indienen voor lekken in een aantal populaire opensource-pakketten en -bibliotheken. Daarmee gaat Google verder dan het louter belonen bij het melden van een beveiligingsprobleem.

De zoekgigant zegt met zijn Patch Rewards-programma iets anders te willen proberen dan de traditionele 'bug bounties' die door diverse bedrijven worden georganiseerd. Het moet softwareontwikkelaars en beveiligingsdeskundigen aanmoedigen om naast het vinden van bugs deze ook te repareren via een werkende patch.

Het Patch Rewards-programma richt zich op opensource-software die op internet veel gebruikt wordt, zo stelt Google. Het bedrijf gebruikt echter zelf ook vrijwel alle genoemde software. Zo wordt onder andere OpenSSH en BIND genoemd, maar ook bibliotheken als zlib, libjpeg en libpng. Ook bepaalde onderdelen van de Linux-kernel, dat de basis vormt van Android, vallen onder het programma, evenals Chromium en de Blink-browserengine, beide software van Google. Google belooft echter in de toekomst ook andere populaire softwarepakketten aan het beloningsprogramma toe te voegen, zoals Apache, de GNU Compiler Collection en een aantal smtp-deamons.

Google noemt onder andere patches voor veiliger geheugenbeheer en het voorkomen van gevaarlijke aanroepen naar libraries als voorbeelden van patches die voor een beloning in aanmerking kunnen komen. Patches die echter een al reeds bekende bug verhelpen komen niet in aanmerking. Daarnaast moet de patch eerst ingediend worden bij de developers van het betreffende pakket en meegenomen worden in een update.

Vervolgens kan er een verzoek bij Google worden ingediend voor een beloning. Dit bedrag ligt tussen de 500 en 3133,70 dollar. De hoogte van de beloning wordt mede bepaald door de complexiteit van het probleem en de geraffineerdheid van de geboden patch, zo meldt Google. Overigens blijft het zogeheten vulnerability program voor het melden van kwetsbaarheden op websites nog gewoon bestaan.

Reacties (17)

Ik ben een leek op het gebied van programmeren, maar kost het niet ongelooflijk veel tijd om een patch te maken? Een bug kun je volgens mij nog 'tegenkomen' maar een patch moet je zelf schrijven (en ook nog testen). Dus eigenlijk vraag ik mij af: zijn dit redelijke bedragen voor de hoeveelheid tijd die een programmeur er waarschijnlijk in moet stoppen?

Er wordt in het artikel gesproken over veiligheidspatches voor opensource software. Opensource is (normaliter ) gratis. Het moedigt alleen maar aan dat mensen niet alleen bugs melden maar indien mogelijk ook oplossen.
Als het nu ging om het oplossen van bugs in een betaald pakket (meestal closed source), dan heb je gelijk en zijn de beloningen klein. Normaal gesproken krijgen ontwikkelaars geen financiële vergoeding voor het sleutelen aan iets wat opensource is, maar doen ze dat omdat ze dit leuk vinden. (of om van te leren, sommigen voor de credits van de community)

Eigenlijk kan ik zoiets alleen maar toejuichen, aangezien op deze manier het actief oplossen ook een beetje beloond wordt en het niet blijft bij "bugje zoeken en melden". Mogelijk dat de OpenSource community dan ook wat actiever wordt.

Als je kijkt naar het uurloon op basis van het vinden van bugs, en oplossen (dus ook de oorzaak vinden), dan zal dat niet al te hoog liggen, maar het is ook niet voor niets opensource en daarmee gratis te verkrijgen door eindgebruikers.

[Reactie gewijzigd door jbdeiman op 10 oktober 2013 17:01]

Een patch die een programmeur maakt is iets heel anders dan een patch welke een bedrijf voor zijn software aan de eindgebruiker levert. Het is niet één of andere install wizard, maar gewoon een klein bestandje waarin staat welke regels verwijderd en/of toegevoegd zijn en op welke regel wat veranderd is. Deze bestandjes kunnen automatisch gegenereerd worden door een tootlje die de code van voor de fix vergelijkt met de code van na de fix.

Eh, je gaat er gemakshalve even aan voorbij dat het veel gemakkelijker is om een bug te vinden dan een bug op te lossen. Om het op te lossen moet je de broncode doorgronden en daar heb je niet geringe vaardigheden en tijd voor nodig.

De bug daadwerkelijk vinden is meestal al 75% van de oplossing, en ook voor het vinden van de bug heb je kennis van de broncode nodig. Maar misschien gebruiken we een andere definitie van 'het vinden van de bug'.

Dit hangt ervan af. Zelf ben ik software programmeur en maak ik voor eigen software wel patches en updates.

Dit hangt compleet af van de 'bug' in de software, dit kan iets simpels zijn waar je 1 tot 2 dagen aan bezig bent, dit kan ook een probleem zijn waar je meerdere weken aan bezig zou kunnen zijn.

Het moeilijke is de echte 'bug' vinden. Wanneer je deze eenmaal hebt gevonden, is de helft van het werk al gedaan. Software van bedrijven als Google zit over het algemeen wel goed in elkaar. Je moet maar net tegen een bug aanlopen.

31337 = ELEET?

Volgensmij wilde Google een keer een bedrijf opkopen, en toen hadden ze $3.141.592.653,58 geboden

ontopic: Ik vind het een erg goed plan van Google! Maar zijn deze software paketten niet al nagenoeg bug-vrij? De pakketen zijn al vrij oud (Dus veelgebruikt en redelijk veilig bewezen), en niet zo heel erg groot. $3000 voor een patch in OpenSSH levert op de zwarte markt echt een veelvoud daarvan op!

[Reactie gewijzigd door Eloy op 10 oktober 2013 17:01]

Donald Knuth haalt ook zulke geintjes uit met mensen die suggesties geven op zijn boeken:

He used to pay a finder's fee of $2.56 for any typographical errors or mistakes discovered in his books, because "256 pennies is one hexadecimal dollar", and $0.32 for "valuable suggestions".

Versienummering van TeX, ook van Donald Knuth, volgt de decimalen van pi. De huidige versie (sinds 2008) heeft nummer 3.1415926 - http://en.wikipedia.org/wiki/TeX

[Reactie gewijzigd door strompf op 10 oktober 2013 22:08]

Dat was onder andere bij de strijd rond de patenten van Nortel, waar overigens een consortium van apple en microsoft (en anderen) gewonnen heeft.

Ik gok e-Leet, want 1337/leet is an sich al een verbastering van 'elite'

Klopt! Van Wikipedia:

Leet (or "1337"), also known as eleet or leetspeak, is an alternative alphabet for the English language that is used primarily on the Internet. It uses various combinations of ASCII characters to replace Latinate letters. For example, leet spellings of the word leet include 1337 and l33t; eleet may be spelled 31337 or 3l33t.

Vraag me af welke kant dit opgaat. Hoe moeilijk is het om een patch tegen te houden door het vaste team en even later door iemand anders in te laten dienen.

Precies dat was ook mijn eerste gedachte. Als een bedrijf bugs in z'n eigen software beloond weet het bedrijf zeker dat het niet zelf gaat betalen voor z'n eigen werk. Als je daarentegen het bij een open source project doet, betaal je dan ook de ontwikkelaars die er altijd veel vrije tijd in stoppen? En zo ja, wat houdt hun tegen om een fout te introduceren en die daarna er weer uit te halen bijvoorbeeld? Maja, we gaan het zien, sowieso een leuke win win situatie voor zowel google als de community zolang het niet misbruikt word

Als je git / distributed scm gebruikt is dat natuurlijk niet zo moeilijk. Dan staat het redelijk publiek dat developer A het project geforked heeft en hierin een wijziging heeft gemaakt.

Bovendien zijn de bedragen nou ook niet zo hoog dat het echt loont om hier mee te gaan frauderen. Het gaat niet om kinderachtige hobby projectjes, het gaat om software die op vrijwel elke linux server geinstalleerd staat.

Ik heb wel respect voor Google. Ze maken goede producten en het is goed dat ze opensource-software steunen. Ook Android gebruik ik met veel plezier.