Google brengt Chrome 116 uit, eerste versie in nieuwe wekelijkse patchcyclus

Google heeft Chrome 116 uitgebracht. Daarin zitten enkele beveiligingsupdates, maar vooral opvallend is dat het de eerste versie van de browser is waarbij Google een nieuw updateschema volgt voor beveiligingsupdates. Die verschijnen voortaan wekelijks voor de browser.

Google heeft 116.0.5845.96 en 116.0.5845.96/.97 uitgebracht voor Windows, macOS en Linux. Daarin zijn 26 bugs gerepareerd, waaronder een use-after-freebug in de Offline-functionaliteit. Daarvoor heeft Google in zijn bugbountyprogramma 30.000 dollar uitgegeven. Verder zijn er enkele functionaliteiten toegevoegd aan de browser, die vooral voor ontwikkelaars interessant zijn. Zo is er een functie om picture-in-picturebeelden direct als always-on-top te openen en het makkelijker te maken om ontbrekende stylesheets te debuggen.

Chrome 116 is vooral uniek omdat het de eerste versie van de browser is waarbij Google een nieuw securityreleaseschema gebruikt. Het bedrijf kondigde vorige week aan daarmee te beginnen. Chrome krijgt voortaan wekelijks een beveiligingsupdate voor de Stable Channel. Daarvoor kreeg de browser nog een vierwekelijkse milestonerelease en kwamen er periodiek beveiligingsupdates bij.

Volgens Google zit er vaak veel tijd tussen het moment dat er een kwetsbaarheid in Chromium wordt ontdekt en het moment dat die in een nieuwe versie van de browser wordt gepatcht. Nu is die periode gemiddeld vijftien dagen, zegt het bedrijf. Door de releasecyclus korter te maken, hoopt Google dat zogenaamde n-days minder effectief zijn. Dat zijn kwetsbaarheden waarvan de details bekend zijn, maar waarvan de patch nog niet is uitgerold of geïnstalleerd.

Reacties (27)

[mschol]

als het puur bij patches blijft en je niet elke week nieuwe/andere features door je neus geduwd krijgt is het een prima update cyclus
features eens per (half) jaar lijkt me zat

[YopY]

Let wel dat het overgrote merendeel van de features van Chrome 'onder de motorkap' zitten, dwz, ondersteuning voor nieuwe libraries / technieken zodat je wipEout in je browser kunt spelen enzo. Het merendeel heeft de eindgebruiker niet door.

[danmark_ori]

Zou de software toekomst er straks zo uit komen te zien, dat er non-stop geupdate wordt?
Dat rekensnelheid bepalend gaat worden welke verbinding de veiligste is?

[Single_Core]

Dat rekensnelheid bepalend gaat worden welke verbinding de veiligste is?

Dat lijkt mij een vreemd statement, waarom denk je dit?

[danmark_ori]

Zowel goodies als baddies zijn non-stop bezig. Beveiligingsexperts en criminelen, en nog een derde stroom misschien: geheime diensten, overheden, landen ... Dag en nacht bezig om gaten te dichten en om ze te vinden, te creëren. Hoe soft kan software zijn? Als het kennelijk ein-de-loos gepatchted en gereviseerd moet worden... Je ziet toch de trend? De revisie interval wordt steeds kleiner. Ik trek die beweging nog wat verder door, dat is alles.

[pennywiser]

Er zit altijd tijd tussen een vulnerability en de uiteindelijke patch, ik weet niet of je zelf iets in ontwikkeling doet maar een public release cycle van een week zegt mij dat er reeds dag en nacht wordt gewerkt.

[The Zep Man]

maar een public release cycle van een week zegt mij dat er reeds dag en nacht wordt gewerkt.

Het zegt mij dat wekelijks gewerkt wordt, niet dat men elke dag en nacht eraan werkt.

[graey]

Men werkt echt wel langer aan een patch dan die ene keer per week dat'ie uitkomt. Ga er maar van uit dat men constant aan het programmeren is, en dat er nu een andere release cycle is betekent dat er vaker een tussenstand wordt gepubliceerd, wat eerder meer dan minder werk erbij is.

[Gubbel]

wat eerder meer dan minder werk erbij is.

Dat slaat echt kant nog wal. Er zijn genoeg kleine aanpassingen die gedaan worden die op de plank blijven liggen tot de volgende release. Je kan dit ook zo interpreteren dat ze het werk kleiner maken en dus vaker naar productie kunnen pushen. Nergens is uit af te leiden of er meer of minder werk is dan voor de wekelijkse cyclus.

[graey]

Pfff, daar ben ik het niet mee eens. Releasen kost tijd, vaker een release doen kost dus meer tijd. Ik kan geen enkele reden verzinnen waarom vaker een build als releasebaar markeren en releasen minder tijd zou kosten. Dat ze het werk kleiner maken lijkt me onwaarschijnlijk, ze schrijven dezelfde patches en updates als nu, ze brengen alleen wat vaker een tussenstand uit. Het is niet alsof ze dat ontwikkelwerk eerder niet deden.

[Gubbel]

Releasen kost tijd, vaker een release doen kost dus meer tijd.

Dit is helemaal geen gegeven?
- Je maakt een Pull Request aan
- Je pipeline bouwt automatisch je QA omgevingen
- Je pipeline draait alle tests en analyses
- QA doet z'n ding
- Je merged je Pull Request naar de release candidate
- De RC pipeline bouwt alles op elke merge
- En zo heb je continu een release versie klaar liggen die zo de deur uit kan.

[Niosus]

QA doet z'n ding

Dat kleine zinnetje, daar zit nu net al het werk. Ja de build maken kost geen werk. Maar zeker zijn dat de build die je hebt oke is om te releasen, dat is nu net wat releasen kostelijk maakt. Je kan zo veel automatiseren als je wilt, uiteindelijk gaan er toch echt nog mensen het product moeten starten en gebruiken om echt zeker te zijn dat alles in orde is.

Als er iets is waar Google innovatie gaat gedaan moeten hebben voor die wekelijkse releases in orde te krijgen, dan gaat dit absoluut op QA gebied zijn.

[Gubbel]

Daar kan veel werk zitten, het kan ook een kwestie zijn van geautomatiseerde e2e tests schrijven en hun ding laten doen. Dan alsnog, als QA niet klaar is, dan gaat dat betreffende stukje werk gewoon mee in de volgende release cycle, dat is juist het hele punt.

[xorinzor]

Vergeet niet dat het hier om veelal om veiligheidspatches zal gaan, en niet zozeer complete nieuwe features.

Daar zit qua hoeveelheid werk en impact wel een enorm verschil in.
Een wekelijkse release cycle zegt niks over wat er in elke release meegenomen wordt, kan best zijn dat pas 1x in de maand alle nieuwe features meegenomen worden.

[graey]

Afhankelijk van de grootte van je team/project en inrichting, heb je naar een release toe eerst mogelijk een freeze, zullen je teams moeten beslissen welke dingen uit welke branches klaar zijn om te mergen, moet dat wellicht ook in overeenstemming worden besloten.
Dan kan je inderdaad, als de release branch er klaar voor is, de boel in gang zetten.
Dan is 'QA doet zijn ding' nogal een stap, zeker bij een project als Chrome, waarbij een noemenswaardige regressie introduceren miljoenen mensen zal raken.
Ja, je kan veel dingen in je release pipeline automatiseren, maar nee, bij een groot project als Chrome is dat geen zero effort-situatie.

[Soldaatje]

Dat de interval kleiner wordt zegt niets over het aantal patches die erin verwerkt worden, alleen dat ze sneller bij de eindgebruiker terecht komen. Voor de rest heb je gelijk maar dat software niet meer soft is snap ik niet. Als je het vergelijkt met hardware dan zit je aan een updatebeleid van meerdere jaren, namelijk als de hardware vervangen wordt, hoewel die bugs dan weer op te vangen zijn door de software.

[machiel]

Ik denk dat het ook die kant en hoop dat we eens terug gaan naar de tekentafel mbt hoe we software maken.

[Newbey]

Zoiets als Linux? Bijna dagelijks verbeteringen van het OS en programmatuur.

[Reactie gewijzigd door Newbey op 22 juli 2024 21:13]

[Blokker_1999]

Linux is een slecht voorbeeld, het is niet 1 product van 1 vendor. Dat er dagelijks updates zijn komt omdat je duizenden teams en honderden bedrijven hebt die bijdragen en wanneer zij een patch hebben, die gewoon committen en deze vrij bruikbaar is. Het zou zijn alsof elke dev van Chrome bij Google zijn eigen commit zou kunnen doen en je elke paar uur bijna een bijgewerkte versie zou hebben.

[jaapzb]

Dat heet continuous deployment en op heel veel plekken is dat al realiteit. Belangrijk is om goede safeguards te hebben zoals een rigoreuze testsuite, zodat je zeker kan zijn dat je wijzigingen niks stuk maken.

Kan me wel voorstellen dat een bedrijf met de resources van google dit zouden kunnen regelen voor een programma als chrome.

Steam heeft ook nagenoeg dagelijks updates.

[Gubbel]

Continuous deployment werkt echt niet zo goed wanneer je client geüpdatet moet worden. Als je daadwerkelijke kunt deployen ja, maar in het geval van Chrome moet je toch degelijk een release uitbrengen die vervolgens door systemen gedownload en geïnstalleerd moet worden.

Overigens wel fijn dat de cyclus versneld is.

[YopY]

Daarnaast; je hebt de Linux kernel die een redelijk vast release-schema heeft, en daaromheen de duizenden libraries, software pakketten en distributies die allemaal releases maken.

[TheVivaldi]

Dat klopt, maar Linux in zijn algemeenheid is geen rolling release. Zelfs als je Linux niet heel letterlijk als kernel neemt, dan nog zijn er tig distributies met allemaal hun eigen updatebeleid.

[Teun!]

Waarvan er wel een aantal het rolling-release model hebben natuurlijk.

[djwice]

Volgens Google zit er vaak veel tijd tussen het moment dat er een kwetsbaarheid in Chromium wordt ontdekt en het moment dat die in een nieuwe versie van de browser wordt gepatcht. Nu is die periode gemiddeld vijftien dagen, zegt het bedrijf. Door de releasecyclus korter te maken, hoopt Google dat zogenaamde n-days minder effectief zijn.

@TijsZonderH De 15 dagen zijn als volgt berekend. Aangenomen dat elke dag een kwetsbaarheid bekend kan worden is de gemiddelde tijd tot de release de helft van de release tijd:

Tot nu toe was dat 365/12/2 ~= 15 dagen.
Nu wordt dat 365/52/2 ~= 3,5 dag.

[beerse]

Dat een software product 1 keer per week of 1 keer per maand wordt bijgewerkt zal voor het verbeteren van zero-day-issues niet veel uit maken. Het zou beter zijn als het gewoon voor de laag weg wordt uitgebracht: Als het klaar is, als het af is. Maar dat hebben we jaren geleden al verlaten.

Als er vandaag een zero-day-issue gevonden wordt, dan moet dat worden opgepakt, de verbetering moet worden aangebracht en er moet iets getest worden. Stel dat dit een doorlooptijd heeft van 10 dagen... Dan zal het in een maandelijks schema in de regel bij de eerst volgende update zitten en anders bij de daar op volgende. Bij een wekelijkse patchronde zal het bij de eerst volgende patchronde zeker niet worden bijgewerkt maar bij de daar op volgende wel. Dat is dan wel 'sneller' maar bedenk ook dat het patch-team iedere week een test-en-release ronde moet doen in plaats van 1 keer per maand.

Toch moet ik even aan het zwangere vrouwen dilema denken: 1 vrouw kan in 9 maanden een kind baren. 9 vrouwen kunnen dat niet in 1 maand... Zo is het ook met patches en dergelijke.