Mozilla biedt 10.000 dollar voor bugmeldingen nieuwe certificatenbibliotheek

Mozilla heeft een nieuwe bibliotheek ontwikkeld voor Gecko, de engine van Firefox, die ssl-certificaten moet verifiëren. De nieuwe code zou robuuster en efficiënter zijn en de ontwikkelaar heeft een beloning van 10.000 dollar uitgeloofd voor het rapporteren van lekken.

Firefox 31, dat op 31 juli moet uitkomen, bevat de versie van Gecko met de nieuwe bibliotheek, meldt The Next Web. In vergelijking met het huidige verificatiesysteem in Firefox wordt de verificatie van het certificaat in de nieuwe bibliotheek grondiger uitgevoerd. Daarnaast is de nieuwe code ook efficiënter en is deze makkelijker te beheren, zo claimt de browserbouwer.

Het verificatiesysteem in de huidige versie van Gecko bestaat uit meer dan tachtigduizend regels code die automatisch zijn vertaald van Java naar C. De nieuwe bibliotheek is geschreven in C++ en beslaat slechts 4167 regels code tegenover meer dan 81.000 regels in de vorige library. Daarnaast wordt er gebruik gemaakt van technieken om efficiënter met het geheugen om te gaan.

Mozilla raadt beheerders van websites aan om de testversie van Firefox 31 te installeren om te checken of hun website werkt met het nieuwe verificatiesysteem. Ook hoopt de ontwikkelaar dat veiligheidsexperts de nieuwe bibliotheek grondig zullen testen. Voor veiligheidslekken die aan bepaalde eisen voldoen kunnen onderzoekers een beloning van maximaal 10.000 dollar ontvangen.

Reacties (33)

Voor 10,000 euro per bug is het denk ik voordeliger voor mensen om ze te verkopen op de zwarte markt. Het schijnt dat prijzen voor dit soort dingen daar richting de 20,000 lopen. Maar het is een goede stap in de richting.

Voor 10,000 euro per bug is het denk ik voordeliger voor mensen om ze te verkopen op de zwarte markt.

Je moet dan wel het risico accepteren dat mogelijk iemand anders dezelfde bug vindt en deze wel netjes rapporteert.

Dat is denk ik meer het risico van de koper van de bug op de zwarte markt, dan voor de vinder (en dus verkoper) van de bug

Je krijgt natuurlijk niet alleen 10.000 dollar (niet euro) maar ook publiciteit als beveiligingsbedrijf bijvoorbeeld, en wereldwijd in de ICT wereld bekend staan als een bedrijf wat SSL beveiliging opschroeft na de Heartbleed bug is de perfecte publiciteitsstunt.

Frappant om te zien dat 80.000 regels java te vertalen zijn in 4.000 regels C++, niet de helft (al heel wat) maar 1/20! En dat terwijl Java in mijn ogen de taal voor prototyping is en c (en C++) de talen voor het echte werk.

Het zijn 80.000 regels code in C die vertaald zijn vanuit Java, waarschijnlijk zou daar ook flink wat omslachtige code inzitten.

Dat kan je rustig aannemen ja. Ik heb wat ervaring met het automatisch vertalen van de ene programmeertaal naar de andere (meestal van hoger naar lager) en daarbij krijg je vrijwel altijd een behoorlijke vermenigvuldiging van het aantal regels code. Als je echt snel en zuinig wilt programmeren, moet je het nog steeds in assembly doen (of eventueel zelfs direct in hex-code inkloppen).

Nee, je programmeert het in C++ en laat de compiler de geoptimaliseerde assembly maken. Zelf assembly bakken is iets van 15 jaar geleden, de compilers van vandaag de dag zijn er veel beter in dan de gemiddelde programmeur.

[Reactie gewijzigd door gimbal op 25 april 2014 16:28]

Je zegt het goed; de gemiddelde programmeur.

Als je het compact (de uit te voeren code) wilt houden en invloed blijven hebben op wat er daadwerkelijk gebeurt, dan zal je naar assembly toe moeten. Die hogere talen voegen naast leesbaarheid (en dat zelfs een huisvrouw kan programmeren) bergen aan overhead toe om het zo breed mogelijk inzetbaar te maken (lees: verschillende CPU architecturen en/of OS'en).

Oorzaak (iedereen wil kunnen programmeren) en gevolg (brak geschreven software)

[Reactie gewijzigd door BlaTieBla op 25 april 2014 17:07]

Neem voor de grap het programma 'hello world' en compileer dat in oude en nieuwe compilers en huiver....

Eerste generatie talen (assemblers en zo) hebben een strakke 1-op-1 vertaling dus weet je precies wat voor code je krijgt.

Tweede generatie talen (macro assemblers en volgens sommigen ook de taal c) hebben al een minder strakke vertaling, voornamelijk door de macro's die meer code genereren dan je denkt.

Derde generatei talen (c, pascal, modula II, en dergelijke) hebben vaak de nodige hoeveelheid (standaard) bibliotheken bij de executables. Maar ook hier is de grootte nog te overzien.

Bij vierde generatie talen is naar mijn idee het hek van de dam. Daar komen de kleinste stukjes code al met garbadge collectors en dergelijke.....

Volgens mij levert assembly geen kortere code dan een hogere programmeertaal. Hoogstens een kleinere binary.

Nee, maar die hogere programmeertaal wordt over het algemeen eerst vertaald naar assembly of iets dergelijks en de resulterende assembly code is over het algemeen wel een stuk langer.

Het goed werken van de certificatenbibliotheek is natuurlijk erg belangrijk, maar eveneens is het verstandig includeren van default certificaten belangrijk. Of het voor de gemiddelde Nederlander namelijk zo zinvol is om CNNIC, CINIC,TURKTRUST of ook een aantal andere CA's standaard als valide CA te acepteren (zoals mozilla en diverse andere browsers en OS doen), is maar de vraag.

[Reactie gewijzigd door begintmeta op 25 april 2014 18:57]

Dat lijkt me toch wel. Het Internet is nou eenmaal wereldwijd. Jij stelt eigenlijk voor dat wanneer een Nederlandse gebruiker een Turkse website wil opvragen eerst een certificaatuitzondering moet gaan toevoegen omdat die website een Turkse CA gebruikt?

Als je dat doet wordt certificaatuitzonderingen toevoegen een dagelijkse kost, en daarmee ondermijn je het hele systeem, omdat gebruikrs dan niet meer kijken wat er aan de hand is. ("Oh de site zal wel in het buitenland staan, want mijn browser niet ondersteund".

Het zal mij wat boeien hoeveel regels code zo'n bieb is. Als het maar werkt. Efficientie is ook niet echt een issue. Hoeveel certificaten staan er nou in? Misschien 20 of 30, en zijn gezamelijk misschien net 1MB.

Bij iets als dit zou ik voor proven technology kiezen.

In vergelijking met het huidige verificatiesysteem in Firefox wordt de verificatie van het certificaat in de nieuwe bibliotheek grondiger uitgevoerd. Daarnaast is de nieuwe code ook efficiënter en is deze makkelijker te beheren, zo claimt de browserbouwer.

Het aantal regels code is dan ook helemaal geen argument om het te vervangen. Bugs zoeken in 8000+ regels automatisch gegenereerde code is wel een stuk lastiger dan in 1100 handgeschreven regels, dat is wel een argument dat het veiliger kan zijn.

Chrome zit al op versie 34 (versie 35 in de bèta). Vind het eerlijk gezegd wel netjes dat ze zoveel versies hebben, geeft in ieder geval de indruk dat ze vaak iets verbeteren!

On-topic:

Wel netjes dat ze dit zo willen gaan oplossen. Meer motivatie = meer aandacht.

[Reactie gewijzigd door eL Bringo op 25 april 2014 13:36]

Versienummer zegt helemaal niets, al helemaal niet als je deze tussen browsers gaat gebruiken.

Maar hoe kan je dan browsers vergelijken? Wat telt er wel?

• Test of de browser de standaarden implementeert
• Test hoe snel de browser is (Javascript engine, HTML rendering)
• Wat is het processor- en geheugengebruik
• Welke features van toekomstige standaarden zijn geïmplementeerd

[Reactie gewijzigd door Junketsu op 25 april 2014 13:37]

Aangezien versienummers niemand iets meer zegt blijkbaar, hier toch even een summiere samenvatting voor Chrome.

Versie die ik draai:
34.0.1847.116

34 is Major Version nummer.
0 is Minor Version nummer
1847 is het Build nummer
116 is het Patch nummer

Uitleg:

• MAJOR and MINOR may get updated with any significant Google Chrome release (Beta or Stable update). MAJOR must get updated for any backwards incompatible user data change (since this data survives updates).
• BUILD must get updated whenever a release candidate is built from the current trunk (at least weekly for Dev channel release candidates). The BUILD number is an ever-increasing number representing a point in time of the Chromium trunk.
• PATCH must get updated whenever a release candidate is built from the BUILD branch.

Bron: http://www.chromium.org/developers/version-numbers

[Reactie gewijzigd door eL Bringo op 25 april 2014 13:46]

Wat hij bedoelt (lijkt me) is dat Chrome 31 niet de concurent van Firefox 31 is, net zoals Internet Explorer 31 dus nog niet bestaat...
Dus Chrome vs Firefox kan je testen, maar het versienummer zegt dus tegenwoordig niets meer over de kwaliteit van de browser, tuurlijk zal 31 beter moeten zijn dan versie 1, maar ik ken eigenlijk geen enkel ander programma wat al op 31 versies zit, en dat geeft eerder de indruk dat er veel te makkelijk een nieuwe versie wordt gereleased ipv dat er echt verbeteringen zijn, of dat er zoveel verbeterd kan worden dat het nu al 31 versies duurt.
Ik kan me nog herinneren dat ik een pop-up kreeg in Firefox voor versie 4, dus dat het nu 'ineens' op 31 zit is dan wel apart.

Die versie nummers zeggen mij nu juist niets meer. Ik gebruik FF wel maar zou geen idee meer hebben welke versie ik draai als ik niet mocht kijken.

Daarom 'quote ik': geeft in ieder geval de indruk dat. Ik zeg niet dat ze daadwerkelijk iets verbeteren, maar onwetenden weten niet beter (duh).

onwetenden weten dan ook niet wat voor versie ze hebben. anders zouden ze er wel vanaf weten. Toch?

chrome zit zelf al op versie 36 in dev versie

En toch zegt mijn Firefox 28, is wel een heel creatieve spelling Als je het hebt over bv de Nightly's, die heten zo omdat ze over-night kunnen veranderen, dus kunnen ze het er alsnog inzetten (mocht dat al niet het geval zijn).

@eL Bringo: De nummeratie zegt ook niet alles natuurlijk, je kan ook wat spellingsfouten fixen en je versie +1 doen. Maar het is een mooie richtlijn, het is wel een indicatie van continue aandacht (kun je bv bij IE lastiger constateren).

[Reactie gewijzigd door Martijn.C.V op 25 april 2014 13:38]

Volgens mij heten het nightly's omdat ze elke nacht gecompiled worden van de up to date source.

Het is natuurlijk puur afhankelijk van hoe je de nummering bijhoud. Ze komen wel aardig in de buurt bij Chrome nu.

Maar als ik zie dat de huidige versie 28 is, dan vraag ik me wel af of ze straks opnieuw gaan tellen met een aangepaste naam, Firefox XP oid?

Wat bedoel je met in de buurt bij Chrome?

Firefox bestaat sinds 2002 (http://nl.wikipedia.org/wiki/Mozilla_Firefox) en is nu bij major versie 31.

Chrome bestaat sinds 2008 (http://nl.wikipedia.org/wiki/Google_Chrome) en is nu bij Major versie 34.

Nu is Chrome sinds het begin al bezig om de 'major' versie omhoog te krikken per release, en Firefox pas sinds 2011.

Ja inderdaad, zelf vind ik dat ze nogal snel gaan. Je zou net zo goed kunnen zeggen dat Firefox nu bij versie 12.31 zit en Chrome bij 6.34

De reden voor de huidige nummering van FireFox was dat mensen het idee hadden dat chrome veel verder/beter was door die hoge versie nummers.
Die achterstand is nu dus 'ingehaald', ondanks dat dit niets zegt natuurlijk