Lang hebben cyberaanvallers kunnen profiteren van een gebrek aan ‘memory safety’. Google is goed op weg om deze klasse aan kwetsbaarheden te elimineren, voornamelijk dankzij code geschreven in het ‘veilige’ Rust. Tegelijkertijd worstelen de maintainers achter deze programmeertaal met burn-out en immense werktaken. Wanneer barst de bubbel?
Bij Google bezigt men de term Safe Coding om naar deze “secure by design”-aanpak te verwijzen. Het speerpunt daarbij is de adoptie van memory-safe programmeertalen. Weg met het C en C++ van weleer dus, met Rust als voornaamste vervanger. Deze modernisering kost nu veel tijd en moeite, zeker als het om kernels gaat. De winst is echter enorm: daar waar gebrek aan memory safety zes jaar geleden verantwoordelijk was voor 76 procent van alle Android-kwetsbaarheden, is dat nu slechts 24 procent. Microsoft is tevens geleidelijk Rust aan het aanbrengen in de Windows-kernel om memory safety te garanderen. Ook iedereen van Dropbox tot Amazon maakt gebruik van de taal.
Lees ook: Waarom programmeertaal Rust steeds populairder wordt
AI kan helpen bij deze modernisering, volgens de Amerikaanse defensiedienst DARPA. Het zogeheten TRACTOR (TRanslating All C TO Rust)-project is door deze instantie voor dit doeleinde opgetuigd. Dat is maar goed ook, aangezien onder meer CISA-baas Jen Easterly onlangs ontwikkelaars de schuld gaf voor het schrijven van onveilige code en alle gevolgen van dien. Ook andere takken van de Amerikaanse overheid, te weten de White House Office of the National Cyber Director, raden Rust aan voor een veiligere IT-toekomst.
Kortom: big tech adopteert Rust en volgt daarin de goede raad van met name de Amerikaanse overheid. De programmeertaal geniet daarmee overduidelijk de voorkeur voor kritieke softwarefuncties anno 2024. Helaas is het Rust-project zelf bezaaid met problemen.
Geen Rust zonder rust
Een hardnekkig probleem onder Rust-maintainers is burn-out. Dat stelde senior engineer Jynn Nelson begin dit jaar. De complexiteit van Rust (dit in tegenstelling tot de oerprogrammeertaal C) is al een stuikelblok voor velen, maar Nelson’s blog stipte een probleem aan dat juist als ervaren maintainer de kop opsteekt. Wie meer taken voor zichzelf opeist, wordt door de community beloond met meer werk. Dit werkt vervolgens averechts: de meest gecommitteerde leden worden overladen met verantwoordelijkheden. “”Het wordt niet gedaan als ik het niet doe” en “ik moet alles controleren, anders glippen er dingen doorheen” is precies de mindset van mijn eigen burn-out door Rust,” aldus de engineer. Het advies van Belson luidt: bied eenzelfde soort documentatie voor burn-out als voor code.
Dit is een welbekend fenomeen bij open-source projecten. Echter is Rust tegenwoordig dermate belangrijk dat overwerkte maintainers een reëel gevaar vormen voor de stabiliteit van allerlei producten. Android, Windows en Linux maken er al in verschillende gradaties gebruik van. En het is niet alsof de taal al zo stabiel is dat er geen zorgen over te maken zijn. In april schudde de zogeheten BatBadBut-kwetsbaarheid het project op met risico’s voor Windows-gebruikers. Wat als een onvoorzien probleem gehele kernel-componenten onveilig maakt? Wie lost het op als de Rust-gemeenschap afgemat is?
Woede-uitbarstingen
Niet allen die stoppen met Rust-projecten, doen dat uit oververmoeidheid. Ook vetes zorgen regelmatig voor problemen. Soms komt dat door keuzes van The Rust Foundation, zoals een overenthousiaste poging om het eigen handelsmerk te beschermen. Het leidde zelfs tot afsplitsers richting een Rust-fork genaamd “Crab”, hoewel dit vooral een manier leek om druk te zetten op de nonprofit die de taal ondersteunt.
Ook het Rust for Linux-project werd onlangs opgeschud. Wedson Almeida Filho, die naast zijn werk als software engineer bij Microsoft vrijwillig dit kernelproject voor Linux leidde, stopte er recent mee. “Niet-technische onzin” zou de druppel zijn geweest. “Na bijna vier jaar verwachtte ik dat we de woede-uitbarstingen van gerespecteerde leden van de Linux kernel-gemeenschap wel voorbij zouden zijn. Ik had gewoon geen zin meer om met ze om te gaan.”
Conclusie: problemen in de verte
Dit alles laat niet zozeer de gevaren van open-source ontwikkeling zien, maar wel die van een gebrek aan sturing. The Rust Foundation biedt financiële steun voor bijvoorbeeld het in de lucht houden van crates.io. Dit is de bewaarplek voor Rust’s equivalent van libraries of packages genaamd crates. Toch is het Rust-project een stuk informeler, gedecentraliseerd en allesbehalve aangestuurd door The Rust Foundation. In tegenstelling tot, pak ‘m beet, Android of Kubernetes, is er niet respectievelijk Google of de Cloud Native Computing Foundation om zaken in het gareel te houden.
Het ligt in de lijn der verwachting dat Rust (of een fork ervan) uiteindelijk een extra evolutie ondergaat. Dit omdat er na de jarenlange transitie van C naar Rust alsnog kwetsbaarheden blijven bestaan, en zal blijken dat niet elk probleem zomaar wordt opgelost. De vraag is wie die taak op zich zal nemen, en of dat net als nu gratis en voor niets is.
Lees ook: Programmeertaal Julia: ideaal voor AI, maar benut potentie niet