Google vervangt fontverwerker FreeType in Chrome door veiliger Rust-alternatief

Google heeft fontverwerker FreeType in Chrome vervangen door een alternatief dat is geschreven in Rust. De nieuwe library, Skrifa, is voornamelijk veiliger op geheugengebied. Ook vereist die minder onderhoud.

Google schrijft in een blogpost dat het de nieuwe library al in Chrome 133 heeft vervangen. Die versie kwam in februari uit. Google heeft daarin FreeType vervangen door een eigen alternatief, genaamd Skrifa. Dat gebeurt alleen in de browsers voor ChromeOS, Linux en Android.

FreeType en Skrifa zijn verwerkers voor fonts in de browser. Die worden aangesproken door de graphicslibrary Skia om bijvoorbeeld metadata van fonts in OpenType-formaat in te laden. Die library is volgens Google veelzijdig en complex, maar kent ook veel beveiligingsrisico's. Met name bij geautomatiseerd fuzzen is het vrij eenvoudig kwetsbaarheden in de library te vinden. Google zegt dat een voltijdprogrammeur een kwart van diens werktijd al kwijt is aan alleen het bijhouden van fuzzingbugs in FreeType.

Google vervangt die library daarom nu door een eigen implementatie, Skrifa. Die is in Rust geschreven. Rust is een programmeertaal die met name beter beveiligt tegen bugs die via het geheugen worden uitgebuit. Skrifa zou met name het aantal out-of-boundsbugs in het geheugen moeten verlagen.

Reacties (83)

[:murb:]

Toch grappig dat Rust wordt gebruikt terwijl het uit de stal van Chrome-uitdager Mozilla komt: Wikipedia: Rust (programming language)

[HollowGamer]

Er zijn nog zoveel meer ideeën die uit de bus komen van Mozilla, maar helaas zijn hun board members daar niet zo geïnteresseerd.

Op Rust hadden ze echt wel iets kunnen verdienen, ik noem maar licenties of een heel ecosysteem eromheen bouwen met lessen en seminars.

Bij Mozilla plannen ze liever een duur feestje en geven ze de CEOs een flinke bonus. De mensen met ideeën gaan eruit, maar de directie wordt wel uitgebreid.

[UPPERKEES]

Een licentie waar je voor moet betalen? Je klinkt zelf een beetje als een Mozilla board member

[Reactie gewijzigd door UPPERKEES op 21 maart 2025 16:40]

[HollowGamer]

Ik ben geen expert, maar ze hadden inderdaad iets als Qt kunnen doen. Zelfde dacht ik dat C# iets in die richting had.

Begrijp mij niet verkeerd, prima dat het allemaal zo open is, maar ik bedoel meer dat Mozilla gewoon echt goede dingen ontwikkeld, maar dan pas loopt buiten hun heen (Thunderbird is daar ook een voorbeeld van).

[graey]

Iets als Rust had nooit tractie gekregen als er een betaald model op lag. C# an sich heeft dat ook niet; alleen de MS runtime + dev tools hadden jaren een gratis (maar niet vrije) tier. De taalspec zelf is vrij beschikbaar en met Mono/Xamarin is er al jaren een volledig vrije implementatie van, minus wat MS-specifieke zaken.

[HollowGamer]

Ik bedoel niet perse de taal zelf, maar alles eromheen.

Mozilla had echt Rust kunnen promoten zoals Google dat heeft gedaan met Go bijvoorbeeld.

[graey]

Promoten? Dat is redelijk gelukt volgens mij, je kan bijna niks doen zonder dat iemand vraagt 'maar waarom niet met rust?'. Een IDE aanbieden is een ander project, dat zou Mozilla ook nog kunnen doen, maar volgens mij bieden ze juist graag goede integratie met open standaarden zodat elke dev het in zn eigen voorkeursomgeving kan gebruiken. Hoe hadden ze het verder moeten promoten of uitbuiten? Met Google als platinum sponsor, en sowieso een lekker aantal participanten en gebruikers, lijkt me het toch gewoon een geslaagd langetermijnsproject geworden?

[Kun]

Het is de beste tool voor de job. Ook is Google nu een platinum sponsor van Rust waar Mozilla "slechts" een silver sponsor is (https://rustfoundation.org/members/).

[PageFault]

Lijkt inderdaad dat Rust ook de ondergang geworden is voor Carbon, wat door Google gestart is en nu nog steeds niet live is.

[84hannes]

Lijkt inderdaad dat Rust ook de ondergang geworden is voor Carbon, wat door Google gestart is en nu nog steeds niet live is.

Ik was Carbon alweer vergeten, maar ik denk dat je conclusie te kort door de bocht is. Carbon is aangekondigd in 2022 8 jaar na Rust 1.0 , 3 jaar nadat Google begonnen was om naar Rust over te stappen. Met andere woorden: Google wist heel goed wat ze wel en niet van Rust konden verwachten toen ze een Carbon begonnen, en wat ze wilden was betere integratie met C++.

Wat wel de doodsteek kan zijn voor Carbon is het initiatief om Rust en C++ beter te laten samenwerken, voor een leuk deel betaald door... Google.

In 2024, Rust Foundation Platinum Member Google generously contributed $1M USD to help the Rust Foundation improve the state of interoperability between the Rust and C++ programming languages.

[Fireshade]

Google heeft gewoon gekeken naar welke techniek sneller en beter resultaat oplevert voor hun projecten, die ook niet oneindig kunnen wachten. Gewoon een rationale beslissing om op meerdere paarden te wedden, en dan de beste te kiezen op dat moment.
Rust was vergeleken met Carbon al veel verder 'gerijpt'. Ik denk dat als Google ook 1 M USD extra gestoken had in Carbon, dat Rust nog steeds de verstandigere keuze zou zijn geweest.

[84hannes]

Rust was vergeleken met Carbon al veel verder 'gerijpt'.

Ik denk dat Rust ook een stukje ambitieuzer is.

[webster]

Gewoon uit nieuwsgierigheid: hoeveel manuren (mensuren?) programmeerwerk zou je krijgen voor $1M USD?

[P_Tingen]

Hangt uiteraard van je tarief af, maar uitgaande van $100 / uur is dat 10.000 uur, oftewel zo'n 1250 werkdagen, dus 5 mensen een jaar lang.

[PageFault]

Dat klinkt plausibel, maar ik vind het jammer dat Carbon nog steeds geen beta is ontgroeid. Je kunt alleen wat online aanklooien, maar niks lokaal serieus proberen.

[mark14]

Zoals ik het begrijp heeft Carbon een heel ander doel dan Rust en daarbij dus ook een ander release pad.

Rust begint zich te ontvouwen als een C++ opvolger.

Carbon lijkt een beweging vanuit Google te zijn die het oneens is met de weg die het C++-standaard committee opgaat (o.a. nooit legacy loslaten) en voor 'geautomatiseerde refactoring van bestaande C++' code is.
Oftewel Carbon is een oplossing voor oude C++ code die bijna niemand aanraakt (maar waar je niet snel van af komt) zodat deze alsnog in een gezonde staat komt.

Bron:
* Carbon is a project to investigate the possibility of a large-scale reduction of C++ technical debt via automated code migration.
* Many so-called ‘successor languages’ are nothing like this. They don’t make automated code migration an explicit goal, and generally build a layer of abstraction on top of or rely on their host language.
* All of this is downstream of Google’s disagreements with the C++ Standard Committee. In fact, while all of this is about reducing technical debt, it’s also about reducing the organizational costs involved in having to coordinate migrations and language evolution with the committee.
* Developing a new programming language is probably necessary to achieve the goals of the project.

https://herecomesthemoon....carbon-is-not-a-language/
https://herecomesthemoon.net/2024/11/two-factions-of-cpp/

[Reactie gewijzigd door mark14 op 21 maart 2025 14:52]

[:murb:]

Zonder Mozilla was Rust er niet geweest. Toen Mozilla in 2020 de investeringen in Rust en Servo stopte spande het er ook om. Gelukkig is het goedgekomen. Zelfs servo lijkt weer tractie te krijgen.

[markg85]

Dat zou ik niet zo stellen. Rust is begonnen als een hobby project en is dat gebleven vanaf 2006 tot 2009. De hobbyist - Graydon Hoare - tevens Mozilla medewerker is pas in 2009 over zijn project bij Mozilla gaan praten. Zo is het balletje gaan rollen en is het een Mozilla project geworden. Het succes van de taal is zeker voor een groot deel aan Mozilla te danken maar denk dat een dergelijke taal ook wel van de grond was gekomen bij een andere bedrijven. Veel talen zijn in die tijd ontstaan (typescript: 2010, go: 2007, swift: 2010, en zo zijn er in de 2010s nog wel meer ontstaan).

[elmuerte]

Google heeft meer geld te verbranden dan Mozilla. Maar gelukkig dat Google nog wel wat teruggeeft aan de OpenSource projecten die ze gebruiken waar zij zelf niet de macht voeren.

[Reactie gewijzigd door elmuerte op 21 maart 2025 08:46]

[downtime]

Google gebruikt vrijwel elke programmeertaal onder de zon. Best tool for the job. En elke taal die Google zelf maakt is voor hun gewoon een kostenpost want ze leven niet van het verkopen van development tools. Ze leven van advertenties.

En ze zijn niet de enige. Vorige week was in het nieuws dat Typescript naar Go wordt omgezet hoewel het een Microsoft-project is en C# misschien meer voor de hand had gelegen. Maar Go was in dit geval blijkbaar geschikter en dus hebben ze Go gekozen. Best tool for the job.

[SPee]

Toevallig is Go (lang) ook gemaakt door Google.

[downtime]

I know.

[The Zep Man]

Toch grappig dat Rust wordt gebruikt terwijl het uit de stal van Chrome-uitdager Mozilla komt: Wikipedia: Rust (programming language)

Beursgenoteerde bedrijven pakken wel eens zaken over van de community. Daar is dit een voorbeeld van.

De community pakt wel eens zaken over van beursgenoteerde bedrijven. Zo wordt zstd bijvoorbeeld gebruikt voor compressie van Arch Linux packages.

[Reactie gewijzigd door The Zep Man op 21 maart 2025 08:49]

[gimbal]

Niet veel meer grappig dan dat "Microsoft" Google's Go gebruikt voor de volgende implementatie van de Typescript processor. Ik schrijf Microsoft tussen quotes want het is niet Microsoft als zelf-bewuste entiteit wat een dergelijke beslissing neemt. Het zijn mensen ergens in de gewelven van Microsoft die dat doen.

Het is geen competitiestrijd, er is geen kinderachtige ban op tools uit de stal van anderen. Men doet gewoon goed werk.

[BugBoy]

-laat maar- @gimbal was mij ruim voor

[Reactie gewijzigd door BugBoy op 21 maart 2025 14:58]

[Roko]

Hoop vakjargon, geen idee waar het over gaat, maar dat kan ook komen omdat het artikel meer leest als een soort opsomming dan als een uitleg.

[GertMenkel]

Dat is voor mij eerlijk gezegd de reden dat ik nog op Tweakers kom, en niet de techsectie van nu.nl voor mijn nieuws gebruik. Alle andere Nederlandse nieuwsmedia (en ook steeds vaker Tweakers) willen nog wel eens termen versimpelen, interpreteren, opnieuw uitleggen, en een alinea aan nieuws in een pagina aan context stoppen.

Ik heb geen kaas gegeten van hardwareontwerp maar ik heb liever dat ik moet Googlen (of in de comments moet zoeken) dan dat alles voor me wordt uitgezocht. Helemaal omdat veel media, waaronder soms ook helaas Tweakers, technische onderwerpen of termen verkeerd interpreteert en een heel ander verhaal maakt van een nieuwsbron dan wat we daadwerkelijk staat of gebeurt.

[DeTeraarist]

Uhm, lees je het zelfde artikel als dat ik doe? Het enige vakjargon wat er voorbij komt is fuzzen en daar hangt nog een link achter ook. De overige 'gekke' woorden zijn namen van libraries.

[bzuidgeest]

Verbazend veel mensen op Tweakers zijn geen technici of developers. Voor die groep is dit al veel.

[Umbrah]

Sorry, maar eigenlijk hoop ik, en het spijt me heel erg als dit wat als gatekeeping overkomt, dat JUIST dat technische/developer-centrische hier blijft. Met dit account zit ik bijna 20 jaar op dit platform, daarvoor had ik ook een account, niet gebanned ofzo, maar vanzelfsprekend heb ik daar geen toegang meer toe.

In die tijd was ik een studentje, en wist ik deze dingen ook niet, maar juist omdat Tweakers een "don't pull punches" schrijfstijl had, en inspireerde met: "dit kan dus ook". Dit artikel vindt ik daarom perfect, er zit een rode draad in, het legt het goed uit, en hoewel er vakjargon/productnamen in zitten, is het allemaal wel te vinden en gaat het er niet om óf je het snapt, maar dat je het in ieder geval zelf kan opzoeken.

De doelgroep voor Tweakers moet, om de developers/techneuten/"tweakers" vast te houden JUIST niet te veel ponyforum worden. Gelukkig heeft Tweakers regelmatig "samenwerkingen", zoals de samenwerking met bokt.nl; een ponymeisjes forum:

nieuws: Tweakers en Bokt.nl beginnen gezamenlijke datingsite

En anders af en toe schrijven ze wat simpelere artikelen op DPG-zustersites: https://www.nu.nl/tweakers

Maar laten we alstjeblieft de kerngroep hier gaan vervreemden. Ik wil me juist niet inhouden als ik wil praten over de laatste artikelen waarbij iemand een volledige LCARS-port heeft weten te bakken naar een duotronische interface waardoor meerdimensionale fast-fourier transformaties in real-time kunnen plaatsvinden waardoor we, wederom, WEP hebben weten te kraken.

[torp]

Maar laten we alstjeblieft de kerngroep hier gaan vervreemden.

Ik snap niet heel veel van je verhaal maar ik neem aan dat je bedoelt:
"Maar laten we alsjeblieft de kerngroep hier niet gaan vervreemden."

[reinouts]

Heb je de datum van dat datingsite-artikel al eens goed tot je laten doordringen?

[bzuidgeest]

Ik heb wel vaker een opmerking geplaatst dat het niveau van sommige artikelen daalt. Steevast krijg je de opmerking dat ze ook voor niet technische mensen schrijven. Voor mensen die alleen geïnteresseerd zijn in het nummertje van de videokaart die ze moeten kopen en verder er niets van weten en begrijpen.

Persoonlijk begrijp ik die houding van een techsite niet, anders dan om breder publiek en dus makkelijker verdienen. Wat natuurlijk belangrijk is voor een bedrijf. Maar dan moet je in de eerste plaats geen techsite runnen. Zeker geen Nederlandse, dan is een heel klein publiek relatief.

Het is wat het is.

[pe0mot]

Geen probleem. Snap je het niet dan zijn er altijd twee oplossingen:
1 wegswipen, er is zoveel te lezen op Internet en op deze site,
2 verdieping door te onderzoeken wat het betekent, blijven leren is goed voor lichaam en geest.
Succes met de keuzes die ons elke dag weer worden gegeven.

[Fox Hound]

Ik vraag me hierbij twee dingen af:
1. Waarom niet op iOS, macOS en Windows?
2. Waarom wordt dit niet voor meer gevoelige delen van een browser gedaan zoals verwerking van afbeeldingen en pdf’s?

[Ablaze]

Het kan, maar iets opnieuw opzetten is altijd veel meer werk dan je denkt. Je merkt pas hoeveel tijd programmeurs voor decennia in een stukje software hebben gestoken als je erin duikt.

Daarnaast is het ook niet lekker wegkloppen in Rust vind ik, het is minder rechttoe-rechtaan dan C++ en je moet allerlei technieken toepassen om de compiler blij te maken. Ik denk dat dat de reden is waarom vooral delen van software worden omgezet en grotere projecten als browsers vooralsnog falen.
Met de opkomst van AI zou het ook goed kunnen dat C++ nog een boost krijgt, het is mogelijk om de menselijke fouten die C(++) onveilig maken al development-time op te sporen.

[bzuidgeest]

Zat mensen die rust makkelijk genoeg vinden. Ik denk niet dat je jou voorkeur zo moet projecteren.

Ik ga ik niet zeggen dat c++ dood is, maar het heeft wel meer problemen dan alleen gebrek aan compiler waarschuwing. Er zijn nu zoveel potentiële vervangers beschikbaar dat ik verwacht dat c++ langzaam verdwijnt. Tenzij een project als carbon werkelijk iets word.

Het is niet alleen rust, je hebt zig, go en zoveel meer. Allemaal capabel, en veel minder rommelig en minder legacy.

[TheVivaldi]

Misschien ligt het aan de techsites die ik volg, maar ik zie steeds meer projecten overstappen op/beginnen met andere talen dan C++. Er zit nog wel C++ tussen, zeker, maar de opkomst van andere programmeertalen is wel in volle gang, waaronder Rust en Go.

Ik verwacht echter dat C++ niet zomaar zal verdwijnen. Ik denk dat het meer zoiets is als met IRL-vervoersmiddelen: de ICE-auto is zeker niet dood, maar je ziet wel dat steeds meer mensen een EV rijden, vaker het OV of de fiets pakken en andere vervoersvormen uitproberen (bijv. elektrische steps). C++ is hier de ICE-auto.

[bzuidgeest]

Ja dat is min of meer hoe ik het ook zie. Daarom wilde ik c++ niet dood verklaren. Voor embedded toepassingen en alleen al de bestaande codebase in de wereld is het voorlopig niet dood. Maar alle pogingen die ik gezien heb om "orde" te scheppen in de c++ wereld lijken op niet veel uit te lopen. Nieuwe als Rust en Go en Zig komen allemaal met een vorm van packagemanagement en volledig geintegegreerde build tooling. In c/c++ is alles beschikbaar wat die andere talen hebben, maar je moet het zelf bij elkaar rapen en iedereen gebruikt een andere combo. De standaard zelf heeft zoveel versies die onderling door elkaar gebruikt kunnen worden dat ik het niet meer kan volgen. Nu ben ik geen c++ programmeur, dat dat kan mijn issue zijn. Maar als ik videos kijk over dingen als googles carbon (geen idee of dat voortgang heeft) dan spreken ze over allerlei issues die de nieuwe talen gewoon niet hebben.

[Ablaze]

Maar het ligt er maar helemaal aan wat je maakt.
Als je een core component of driver maakt, dan kun je niet met Go aankomen, want het is standaard niet low level genoeg en heeft een garbage collector. Als je embedded (bare metal of met een klein OS) programmeert dan kiest men bijna altijd voor C of C++, want daarvoor is verreweg de meeste support en met C kun je veel makkelijker goochelen met pointers, wat vaak noodzakelijk is in microcontrollers met een geheugenruimte uitgedrukt in kilobytes.

De vergelijking tussen ICE en EV is moeilijk te maken, omdat je het over zoveel toepassingsgebieden hebt. Sowieso levert C of C++ al snelle en kleine binaries dus het gaat puur om de veiligheid en gebruiksgemak, niet om performance.

C++ vs Go niet als een ICE vs EV, meer als een handgeschakelde auto en een automaat. En C++ vs Rust meer als een traditionele vs een met allerlei veiligheidsfuncties.

[Oudecomputer]

Zo lang mensen programmeren is rust niet veiliger.
2 C++ is sneller in heel veel meer taken. Danheel verl andere talen.
3 er zitten nog heel veel bugs in rust en de compiler!

C++ is niet heilig maar alle bugs zijn bekent. Rust is nieuw en ja geheugen is veiliger geprogrammeerd maar bug ? Veel zijn onbekend.


Reparaties aan ice autos kun je bij elke garage terecht! Alle onderdelen zijn te krijgen. Heb je een ongeluk met een EV dan heb je serieuze problemen met onderdelen verkrijgen of mensen vinden met expertise.
Er zijn zo veel EV horror verhalen!
Of het bedrijf bestaat niet meer heb je een chinese EV of een dure elektrische fiets en kan je er niets meer mee. En het zijn tikkende vuur bommen!
C++ werkt, niet alles hoeft 1000% veilig te zijn.

Ik vind het veel fe vroeg om zomaar alle key functies over te stappen naar rust... Aangezien we totaal blind zijn voor alle bugs.

[P_Tingen]

Het kan, maar iets opnieuw opzetten is altijd veel meer werk dan je denkt. Je merkt pas hoeveel tijd programmeurs voor decennia in een stukje software hebben gestoken als je erin duikt.

True! Er is echt niets moeilijker dan een bestaand systeem vanaf de grond opnieuw bouwen. Je moet alle edge-cases weer opnieuw vinden en programmeren en in sommige gevallen zelfs bewust fouten opnieuw programmeren.

We hebben ooit een programma herschreven waarvan het origineel in Basic was. Dit programma was voor het berekenen van ingredienten maar er zat ergens een fout in met het afronden, ver na de komma. We kwamen daar achter en repareerden dat in het nieuwe programma. Moest maar beter van niet, want nu klopten de berekeningen niet meer met wat er in het verleden was berekend en dat zou dus een nieuwe receptuur tot gevolg hebben. Het ging hier om tabak dus dat ligt erg gevoelig

[cdwave]

Met de opkomst van AI zou het ook goed kunnen dat C++ nog een boost krijgt, het is mogelijk om de menselijke fouten die C(++) onveilig maken al development-time op te sporen.

O, ja, als we het niet weten dan gooien we er AI tegenaan. Dat is religie, geen wetenschap.

[Ablaze]

Hoe bedoel je dat? Dit is gewoon concreet.

Als ik bijvoorbeeld VS gebruik met C#, is de intellisense tegenwoordig AI gedreven. Deze herkent wat je wilt bereiken en kan automatisch regels code afmaken wanneer je aan het kloppen bent. Daarnaast is er bijvoorbeeld Copilot integratie die automatisch fouten en potentiële problemen herkent in je code. Alles design time, nog voordat je compileert.

[Mellow Jack]

Met de opkomst van AI zou het ook goed kunnen dat C++ nog een boost krijgt, het is mogelijk om de menselijke fouten die C(++) onveilig maken al development-time op te sporen.

Als je die hebt gevonden hoor ik het graag van je. De AI die ik nu gebruik is dol op het overloaden van geheugen

[Xander2]

Incorrect.

Een font engine is bepaald geen triviaal stuk software met state machine, mathematische functionaliteit en diverse encodings/mappings en gare workarounds vanaf begin jaren 90.

Sommige fonts gebruiken de handling van de integerwrapping in bepaalde engines als feature waar anderen een strikte definitie verwachten. En bedankt C/C++.

Het feit dat je voor dit stuk spaghetti en iteratie ontwerp (wat truetype is, met variabele tables/types/encodings) software binnen korte tijd een stabiel en retesnel alternatief neer kan zetten in Rust (dat lukte mij al voor inlezen ttf en renderen in een paar weken als start hobby en rust leek) dat je voor algoritmen en data structuren op alle fronten beter uitbent dan bij C++ (muv OO ontwerpen als klassieke GUI).

Voor drivers/embedded was C++ eigenlijk al niet geschikt vanwege de Frankenstein van benodigde subset en pragma hell, kan prima in C, als in, enigszins portable en leesbare assembly.

Er zijn zat dingen op Rust aan te merken maar het is wat mij betreft een terechte terugkeer naar striktere Pascal typing , generics die geen kludge zijn en taalfeatures die onderdeel zijn van het ontwerp ipv C++ deze feature is ook handig laten we kijken hoe we dit door de compiler kunnen vrotten zonder al te veel problemen.

En een preprocessor is echt uit de tijd, onmogelijk om daarmee stabiele code af te leveren obv verschillende versies en platforms.

Het OO paradigma heeft z'n merits en past niet binnen rust, maar C++ is een draak die code en data mixt wat al tijden niet meer gewenst is.

[MSalters]

1) Omdat Apple en Microsoft eigen fontverwerkers hebben (in het OS zelf). Het is niet alsof Google daar FreeType blijft gebruiken.

2) Het is een trade off. JPEG decompressie etc is inmiddels wel robuust genoeg; PDF rendering vervangen is duur.

[Xander2]

Moderne OpenType fonts hebben glyphs in postscript formaat. Een font lezer/renderer is praktisch een pdf renderer.

[Jorick]

Zie de blogpost:

Chrome ships with FreeType and makes use of it as the primary font processing library on Android, ChromeOS, and Linux. That means a lot of users are exposed if there is a vulnerability in FreeType

Ik vermoed dat op Windows GDI/DirectWrite o.i.d. wordt gebruikt en op iOS zal Chrome (i.i.ig. buiten de EU) wel gebonden zijn aan wat WebKit als default gebruikt.

[Reactie gewijzigd door Jorick op 21 maart 2025 09:09]

[beerse]

Mijn antwoorden (omdat mijn gedachten toch al die kant op gingen):
1: Apple en microsoft hebben eigen implementaties om fonts te verwerken. TrueType is een term die mij te binnen schiet. Er is meer in die hoek.
2: De gevoelige delen van de browser: daar is dit er 1 van: het verwerken van een beschrijving van een letter naar een setje pixels op het scherm. Met PDF is het vooral meer van het zelfde maar dan net iets anders. PDF heeft een oorsprong in postscript maar gebruikt ongetwijfeld ook de zelfde fonts en dus mogelijk ook de zelfde font verwerkers.

[downtime]

TrueType is geen implementatie maar een standaard voor het opslaan van fontdefinities. TrueType is de oude standaard van Microsoft en die is inmiddels opgevolgd door OpenType wat een gezamenlijk initiatief van Apple en Microsoft is. Daardoor is er tegenwoordig nog maar 1 standaard die op elk OS werkt.

[Stukfruit]

FreeType en Skrifa zijn verwerkers voor fonts in de browser.

Technisch gezien klopt deze uitspraak niet helemaal

FreeType bestaat al sinds 1996 en is in redelijk veel projecten gebruikt, waaronder bijvoorbeeld alles wat je met de gemiddelde GNU/Linux-distributie op je beeldscherm voorbij ziet komen zodra het met letters te maken heeft.

In eerste instantie werd het geschreven op OS/2 (bron: interview op OSnews uit de tijd dat het nog een nieuwssite was) en het is wel eens in opspraak geraakt omdat Apple in de weg zat met patenten, waardoor het in principe niet mogelijk was om letters mooi weer te geven omdat zo'n lettertype een stuk meer informatie bevat dan je als eindgebruiker in eerste instantie zou denken.

[PageFault]

Kortom: de gemiddelde GNU/Linux distributie, waar FreeType ook gebruikt wordt, heeft potentieel ook dergelijke beveiligingsrisico's.

[fenrirs]

Als dat zo was dan waren er vast al honderden exploits te vinden.

Goed dat google hier naar kijkt, maar een nieuwe implementatie, ook al is het in rust geschreven, brengt óók risico’s met zich mee. Al was het maar door de beperkte hoeveelheid ogen die naar die code heeft gekeken.

Daarnaast vind ik het nogal vreemd dat Google blijkbaar een kwart fte kwijt is aan FreeType, terwijl je andere grootverbruikers er niet over hoort (RedHat, IBM etc). Een telefoontje van de redactie naar deze partijen had dit artikel meer waarde gegeven

[Gimmeabrake]

Als dat zo was dan waren er vast al honderden exploits te vinden.

Op het moment van schrijven zijn er 111 CVE's met keyword freetype. Er worden dus wel degelijk af en toe security issues gevonden in FreeType.

Goed dat google hier naar kijkt, maar een nieuwe implementatie, ook al is het in rust geschreven, brengt óók risico’s met zich mee.

Met rust verklein je de attack surface. In de CVE-lijst hierboven wordt ~20x de term "out-of-bounds write" gebruikt, en ~30x "buffer overflow". Dat soort errors zijn in rust bijna niet meer mogelijk. Natuurlijk kunnen er wat kinderziektes in nieuwe software zitten, maar op de lange termijn is een overstap van C(++) naar rust qua security eigenlijk nooit een slecht idee.

Al was het maar door de beperkte hoeveelheid ogen die naar die code heeft gekeken.

Een veelvoorkomend argument, dat in de praktijk geen stand houdt. Mooi voorbeeld is de foute AES-implementatie in 7zip die in 2019 werd gevonden.

[Reactie gewijzigd door Gimmeabrake op 21 maart 2025 09:54]

[Die_ene_gast]

Een veelvoorkomend argument, dat in de praktijk geen stand houdt. Mooi voorbeeld is de foute AES-implementatie in 7zip die in 2019 werd gevonden.

Jouw voorbeeld bewijst toch juist dat het wel werkt? Want juist doordat iemand er naar keek is het probleem opgelost?

[Gimmeabrake]

De bug zat er in sinds 2007 in (versie 4.48 beta, volgens deze bron).

De thread die ik hierboven linkte, begint zo (emphasis mine):

So I wanted to encrypt some files. Thought about using 7z+password. Stackexchange folks said "Didn't review it but it should be fine. You can browse the code yourself".

Hij publiceerde dit januari 2019, dus ik neem aan dat dat in 2018 was. Na 30 minuten review vond hij twee gigantische fouten in de implementatie:

• de IV werd voor de helft leeggelaten
• de random numbers worden niet cryptographically secure gegenereerd

Met andere woorden, één van de meest gebruikte open source archiveringstools heeft van 2007 t/m 2018 een bizar slechte AES-implementatie gehad. Dit zijn geen subtiele bugs, iedereen die AES een beetje kent had dit zo kunnen spotten.

Jij zegt dat het aantoont dat het juist wel werkt, ik denk dat het juist aantoont dat we bij open source software niet automatisch moeten aannemen dat het dan ook wel secure zal zijn, hoe populair het project ook is. Dit is overigens geen pleidooi voor closed source software, die software kan net zo onveilig zijn, alleen is dat dan nog slechter te controleren.

[TheVivaldi]

Exact. Het voordeel van OSS is dat er meer mensen mee kunnen kijken, maar het is geen garantie dat dat ook gebeurt. Als Linux-gebruiker ben ik zeker voorstander van OSS (maar ik gebruik ook heus wel closedsourcesoftware), maar sommige mensen hebben iets te hoge verwachtingen van het meekijken met de commits.

[Die_ene_gast]

Dus wederom bevestig je dat de openheid van de bron ervoor zorgde dat iedereen het kon inzien en fouten vinden?
Hoe is dit een win voor jouw argument?

[Elminster]

En hoeveel CVE's staan er daarvan nog open?
Hoeveel CVE's zijn er gevaarlijk?

Trouwens, CVE's zoals deze: (signed overflow - komt uit de lijst)
https://www.cve.org/CVERecord?id=CVE-2025-23022
Dat is een bug in een 8 jaar oude versie!
Waarvoor er 7 jaar geleden al een bugfix voor was.

Als je dan toch belang hecht aan het aantal:
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust
't Zijn er een beetje meer.

Met dezelfde opmerking als hierboven: Hoeveel staan er nog open? Hoe ernstig zijn die?

[_Thanatos_]

Met als verschil dat een website niet een font je OS in kan duwen, maar een website kan wel een font je browser in duwen.

[PageFault]

Uiteindelijk wordt de code toch uitgevoerd op je computer. Mogelijk komt het niet uit bij je OS, maar kan het wel in de (cookie/session) data van je browser interessante dingen oppakken en doorspelen/misbruiken.

[_Thanatos_]

Maar je mist mijn punt: fonts die in je OS komen, installeer je zelf, dus via die weg wordt je niet gauw geinfecteerd met iets. Dat webfonts alsnog in de browser kunnen iets kunnen uitvreten, zal ik niet weerleggen. Dus je hebt wat dat betreft helemaal gelijk

[TheVivaldi]

Even uit nieuwsgierigheid: ik gebruik de optie om websites niet hun eigen lettertypen te laten kiezen, in Firefox met de bijbehorende optie in de instellingen en in o.a. Falkon met een eigen stijlblad (usercss). Hoe zit het dan met het ‘duwen’? Duwen de websites die lettertypen alsnog en duwen mijn browsers die door mijn instellingen/usercss weg of drukken ze de instellingen/usercss erdoor nog voordat websites de kans krijgen om hun eigen lettertypen af te dwingen?

[_Thanatos_]

Als je zelf gaat rommelen met user css of whatever, dan heb ik geen idee wat er zal gebeuren. En als jouw browser een ingebakken optie heeft om webfonts te blokkeren, ja, dan worden ze geblokkeerd. Hopelijk.

In een normale situatie zal een browser de fonts die een website gebruikt, gewoon downloaden en renderen. Net als css en plaatjes.

[bzuidgeest]

Nauwelijks meer dan windows zou hebben. We hebben over de jaren zat bugs rond fonts gezien op elk Os.

[PageFault]

Gimmeabrake geeft hierboven al aan dat er 111 gevonden CVEs zijn. Ik weet dat de ene risico het andere niet is, maar ze zijn er wel....

[bzuidgeest]

Enig idee hoeveel CVEs er zijn op windows en zijn fontrendering... Of code acces via een plaatje laden etc etc.. Freetype staat al langer bekend als iets met issues, maar om nou te zeggen dat dit bijzonder uniek is... Daar twijfel ik nog aan.

Maar als google iets beters gemaakt heeft is dat alleen maar goed.

[GertMenkel]

Het artikel geeft aan dat Google beweert een kwart FTE kwijt te zijn aan het patchen van bugs die ze met fuzzing gevonden hebben. Nu zegt dat niet zoveel over de hoeveelheid en ernst van de bugs (de oplossing kan nu eenmaal complex zijn), maar ik vind dat toch wel veel.

Ik geloof dat Microsoft en Apple na een reeks ernstige lettertypebugs de nodige wijzigingen hebben gemaakt. Microsoft heeft de DirectWrite font-code bijvoorbeeld grotendeels omgezet naar Rust en Apple is van jaarlijkse lettertype-jailbreaks naar side notes gegaan. Beide partijen lijken hier een hoop werk in gestoken te hebben, maar het resultaat lijkt me op het eerste oog toch veiliger.

[bzuidgeest]

Je onderschrijt dus mijn opmerking eigenlijk. Zowel Apple als Microsoft hadden problemen met hun font code die verandering vereiste. Dat maakt de situatie in freetype dus niet uniek. En als je ziet hoeveel cve's er zijn over alle fabrikanten denk ik dat er wel meer dan een kwart FTE aan beveiligingsonderzoek achter zit.

Ik heb verder geen probleem met de vervanging an sich. Ik vind alleen dat het artikel het erger doet laten klinken dat het is. Voor een echt oordeel moet je en de ernst van de bugs weten en hoeveel er van die bugs in andere soortgelijke projecten gevonden worden.

Je had onlangs hetzelfde met de ESP chips. Die zouden een "backdoor" bevatten. Niets was echter minder waar en de onderzoeker heeft die claim ingetrokken. Maar de media rent er wel mee weg en iedereen die niet verder las riep oeh en ah. Het ging echter gewoon om commando's voor tests in de fabriek die niet extern toegankelijk waren. Niets geheims, niets gevaarlijks.

[GertMenkel]

Het verschil hier is denk ik dat Freetype niet heel veel structurele aanpassingen heeft gehad (en daarom zelfs compleet vervangen is). Nu dat Chrome niet meer afhankelijk is van Freetype, verliest het project daarmee een kwart FTE aan bugfixes. Voor een open-source project is dat zeer significant. Dat staat niet heel goed voor Freetype.

Re: dat ESP-verhaal: ja, de claims waren overdreven, maar dat zegt niks over andere kwetsbaarheden. De kwetsbaarheid achter CVE-2025-27363 is bijvoorbeeld wel weer gevaarlijk en is een risico voor een hoop ongepatchte systemen (denk: Android).

[bzuidgeest]

Voor een open-source project is dat zeer significant. Dat staat niet heel goed voor Freetype.

open-source misschien, maar chrome is primair google. Ik denk dat die wel een kwart FTE kunnen lijden.

[GertMenkel]

Ja, dat deden ze dus. Maar nu hebben ze de library vervangen door een eigen variant. Ik neem aan dat Google niet voor Jan Joker die library nog gaat maintainen als er een beter, eigen alternatief is. Google is nou niet bepaald een goed doel.

[Reactie gewijzigd door GertMenkel op 21 maart 2025 15:54]

[bzuidgeest]

Het maakte FreeType beter dus het was niet voor jan joker denk ik zo. En iedere gebruiker van FreeType had daar baat bij. Google zou eens een maatschappelijke bijdrage kunnen doen...
Het is dat de nieuwe onder een MIT licentie is gepubliceerd. Dus anderen kunnen het ook gebruiken.

[GertMenkel]

Ja, het verbeteren was goed voor iedereen natuurlijk, maar als Google de library niet meer nodig heeft en daadwerkelijk zoveel mankracht kost om veilig te houden, denk ik eerder dat het management van Google gewoon opgeeft.

Het fuzzen gebeurt onder oss-fuzz, dat zal nog wel even blijven gebeuren verwacht ik. Voor het patchen zal naar mijn vermoeden op termijn iemand anders op moeten staan. Misschien binnen Google (Android gebruikt ook Freetype) maar dat kan natuurlijk ook iemand van Facebook of Apple of een van de vele andere bedrijven die Freetype shippen, zijn. In de praktijk betwijfel ik dat dit makkelijk zal gaan.

Het nieuwe project deelt niet dezelfde API dus alhoewel het vrij te gebruiken is, zal iedere applicatie daarvoor omgebouwd moeten worden. Chrome had natuurlijk al de nodige Rust-bindings, maar genoeg C/C++/D/etc.-projecten kunnen of willen geen Rust binnentrekken. Als je software op obscure hardware draait bestaat er een kans dat Rust helemaal niet compileert voor je platform, dus zit je vast aan Freetype.

[m798]

Komt het dan ook in de open-souce implementatie van chromium, of is dit proprietary en alleen in Chrome?

[Kun]

Het is open-source: https://github.com/googlefonts/fontations/tree/main/skrifa

[_Thanatos_]

Dus het antwoord is "dat zou kunnen"

[simon]

Op https://chromestatus.com/feature/5717358869217280 (gelinkt in het nieuwsbericht) vind je Status in chromium, en daarbij de bijbehorende versies van Chromium waarin het verwerkt zit. Het zit dus in Chromium.

[djiwie]

Ik snap nu waarom sinds vorige maand de antialiasing specifiek in Chrome op Linux zo brak is. Had al van alles geprobeerd, dacht dat het kwam door een upgrade van Linux Mint... maar dan zal het wel dit zijn

[haling]

Ik snap nu waarom sinds vorige maand de antialiasing specifiek in Chrome op Linux zo brak is.

Mij is eigenlijk helemaal niet opgevallen; zowel in Chrome (werk) als Brave (privé) niet. En ja, ik zit al op Chrome(ium) 134+

[djiwie]

Ik zie een heel duidelijk verschil met Firefox. Chrome is op dit moment een stuk minder scherp.

[Jaapvaak]

Rust is da best