Debian verplicht vanaf volgend jaar Rust-ondersteuning in packagemanager apt

De packagemanager apt krijgt op Debian ondersteuning voor Rust en vanaf volgend jaar wordt die ondersteuning ook verplicht voor alle ports en forks. Een van de hoofdontwikkelaars van Debian wil ondersteuning voor de memory safe toolchain vanaf mei verplichten.

Debian-ontwikkelaar Julian Andres Klode schrijft dat in een mailinglijst. Na mei 2026 worden Rust-dependency's en -code verplicht in apt op Debian. Dat begint volgens hem bij de compiler en bij Sequoia, de Rust-implementatie van OpenPGP. Vanaf mei volgend jaar wordt het verplicht voor alle forks en ports van Debian om Rust te ondersteunen. Dat betekent dat Debian-ontwikkelaars binnen een klein half jaar Rust-ondersteuning moeten toevoegen aan de packagemanager.

Klode merkt op dat de meeste grote Debian-ports in ieder geval al algemene Rust-ondersteuning hebben, al hebben kleine ports zoals DEC Alpha of Hewlett-Packard Precision Architecture (HPPA) dat nog niet. Voor zulke distro's kan het lastig worden goede ondersteuning toe te voegen.

Volgens ontwikkelaar Klode zouden parsers voor bijvoorbeeld .deb- of .tar-bestanden baat hebben bij ondersteuning voor talen die 'memorysafe' zijn. Rust wordt over het algemeen gezien als programmeertaal die veel geheugenbugs kan voorkomen. Veel ontwikkelaars spreken zich in de mailinglijst ook uit tegen de ontwikkeling. Ze vinden de deadline van een kleine zeven maanden voor implementatie erg kort. Klode zegt dat ports die de deadline niet halen op termijn worden uitgefaseerd als officiële Debian-ports.

Reacties (20)

[BezurK]

Wat wordt hier nou eigenlijk gezegd? Wordt heel APT herschreven in Rust? Moeten alle packages die gepubliceerd worden in de Debian repo geschreven worden in Rust? Moeten packages kunnen compilen met de toolchain van Rust? (kan dat uberhaupt?! lijkt me niet)

Ik begrijp niet zo goed wat hij nu precies bedoeld.

I plan to introduce hard Rust dependencies and Rust code into
APT, no earlier than May 2026. This extends at first to the
Rust compiler and standard library, and the Sequoia ecosystem.

Hier lees ik dat hij voor mei Rust code en dependencies wil gaan toevoegen aan APT. Dat klinkt als een solide beslissing. Er wordt op het moment wel meer FOSS deeltje voor deeltje geport naar Rust door stapje voor stapje Rust code te introduceren.

In particular, our code to parse .deb, .ar, .tar, and the
HTTP signature verification code would strongly benefit
from memory safe languages and a stronger approach to
unit testing.

Makes sense.

If you maintain a port without a working Rust toolchain,
please ensure it has one within the next 6 months, or
sunset the port.

Hier gaat het voor mij dus verwarrend worden. Voor zover ik weet is een "port" niets anders dan een package die een core deel van de Debian distro vormt. Een applicatie(tje) dus. In welk opzicht moeten die dan een "working Rust toolchain" hebben ... ?

Wie legt het uit?

[markiemannie]

Met een port wordt geen applicatie bedoelt maar een architectuur. Debian heeft een dozijn officiele en onofficiele ports, niet alleen x86 maar denk aan arm, IBM Mainframes maar ook wat obscuurdere dingen zoals MIPS, PA-RISC en ga maar door. Al deze ports gaan dus een werkende rust toolchain vereisen.

[BezurK]

Ah, dan valt het kwartje! Doordat het over APT ging dacht ik direct aan ports = packages en daar gaat de beredenering dan mank natuurlijk. Niet om per sé mijn gelijk te halen maar volgens mij werden heel veel core GNU tools ook ports genoemd omdat ze "overgenomen" werden uit de Unix wereld. Maar goed, totaal logisch dat de ports waar over gepraat wordt in deze context gewoon architectuur-ports zijn, haha. Thanks :)

[SPee]

Van wat ik hieruit opmaak, is dat ze Rust gaan gebruiken in APT. Dus dat eenieder die APT bouwt vanaf source ervoor moet zorgen dat je ook Rust kan gebruiken tijdens het compileren.

Dus dat geldt voor iedereen die Debian 'port' naar een bepaalde architectuur (x86, arm, etc). En dus ook voor iedereen die een Debian afgeleide maakt en dat vanaf de sources doet (bijvoorbeeld Ubuntu). Als jouw toolset om die port te maken geen Rust ondersteund, dan kun je vanaf dan APT niet meer compileren, omdat een deel ervan in Rust is geschreven. Je zou nog wel een soort Frankenstein distributie kunnen maken, waarbij je een oude APT versie gebruikt, maar er zal steeds meer verschil in komen met steeds grotere kans op problemen en de weigering om jouw specifieke bugs op te lossen in hun code.

Dat langzaam overstappen naar Rust is een beetje mixed. Ja, hiermee zal bepaalde memory issues voorkomen worden. Maar het gaat hier veelal om code die meer dan 20 jaar langzaam geëvalueerd is en die problemen er al uitgehaald zijn. En die robuuste en bekende tools vervangen gaat niet zonder problemen. En ook fouten zoals een verkeerde waarde parsen lost Rust niet op. Enkel dat het geen bufferoverflow of -underflow oplevert. Dus het is nog maar zeer de vraag of het meerwaarde oplevert (in deze context).

[jasper580]

Rust code wordt gecompileerd naar 0'en en 1'en die de computer daadwerkelijk kan uitvoeren. Dat compileren gebeurd door de rust toolchain. Niet elke computer interpreteert die 0'en en 1'en op dezelfde manier: computers verstaan meestal x86_64, terwijl je telefoon arm verstaat.

Wat hier gezegd wordt is dat, als je een port van debian bijhoudt, je ervoor moet zorgen dat rust kan compilen naar jouw variant. Voor de meeste computers is dit al gebeurd, maar voor minder gebruikte architecturen kan het zo zijn dat deze nog niet opgenomen is in Rust. De auteur zegt in de laatste quote in feite: "als jouw architectuur nog niet ondersteund wordt dan wordt APT compileren lastig in de toekomst, zorg dat of 1) rust jouw architectuur support of 2) stop met je port"

[Reactie gewijzigd door jasper580 op 3 november 2025 16:07]

[GertMenkel]

Op zich hoeft een port natuurlijk niet de officiële Rust-toolchain te ondersteunen. Aangezien de enige ports die hier last van hebben zwaar obscuur zijn of geheime/proprietary ports zijn, kan ik me voorstellen dat bedrijven die hun eigen specialistische distro bijhouden eerder de focus zullen leggen om gcc's Rust frontend ondersteuning te geven voor de code die in apt terechtkomt.

Ook kunnen ze een "goed genoege" LLVM-backend optuigen. Voor officiële ondersteuning moet je dingen doen als "ondersteuning garanderen" waar bedrijven als Expressif in het verleden door zijn afgehaakt, maar je kunt ook je eigen fork maken die net goed genoeg is om apt te compileren.

Het mooiste zou zijn als deze obscure platformen ook LLVM/mainstream Rust-ondersteuning krijgen, maar het is niet de enige manier om dat voor elkaar te krijgen.

[Knallmeister]

Lijkt erop dat ze bij Debian de ontwikkelingen van Ubuntu deels gaan overnemen.

YouTube: Ubuntu Linux is Getting Rusty..

Kijk ook naar de Sources

[SPee]

Die overgang gaat niet zonder problemen:

Bug in Rust-Based Uutils Broke Ubuntu 25.10 Automatic Update
Rust Coreutils Are Performing Worse Than GNU

En dan zijn er nog meningsverschillen over de gebruikte licentie; MIT in plaats van GPL.

[Knallmeister]

En dan zijn er nog meningsverschillen over de gebruikte licentie; MIT in plaats van GPL.

Debian heeft zich zeer lang als een van de meest puristische Linux distro's opgesteld door zich expliciet GNU in de naam te vermelden. Zouden ze het aandurven om in de nabije toekomst MIT in de naam op te nemen? Lijkt me niet.

[blorf]

Ik ben een beetje bang dat de PC-industrie via financiering gaat proberen de controle over de machine voor de consument te verkleinen. Nu is het optioneel, maar memory-safe kan er ook op neerkomen dat instructies ontoegankelijk worden gemaakt voor gebruikers die geen kernel van een "whitelist" draaien, wat dan als zwakke beveiliging wordt affespiegeld. In het ergste geval 1 met verplichte binary-data, standaard gemaakt door nVidia en Steam of Microsoft.

[Belboer]

Wat jij beschrijft is trusted computing waarbij binaries ondertekend zijn en niet kunnen draaien als ze geen geldige handtekening hebben. Memory safe heeft daar weinig mee te maken. Dat is dat allocatie, gebruik en vrijgave van geheugen door een proces onder controle staat een mechanisme dat oneigenlijk gebruik tegen gaat. Een memory safe language gaat hele categorieën van kwetsbaarheden tegen zoals buffer overflows, null pointer dereferences, stack smashing etc. Dat is een groot voordeel.

Overigens is trusted computing ook al mogelijk met Linux. Je kan de kernel met secure boot starten en met Linux IMA, SeLinux en AppArmor er voor zorgen dat alleen bekende executables kunnen draaien. Als de kernel met secure boot start accepteerd deze ook alleen ondertekende modules en voorkom je een hoop kernel level rootkits. En met IMA etc kan je er voor zorgen dat malware niet kan draaien. Resultaat is een redelijk veilig systeem.

En dat kan allemaal met je zelf gegenereerde keys. Het is wel een enorme bak werk. En je moet zelf je keys in je TPM laden. Vandaar dat diverse bootloaders door Microsoft ondertekend zijn. De Microsoft keys zitten standaard in de TPM en zo kan je een secure boot machine eenvoudig dual boot maken. Maar dan mis je wel de voordelen van secure boot.

[blorf]

Wat ik bedoel is dat je in een willekeurig stuk programma een instructie niet kan uitvoeren omdat het als memory-unsafe wordt beschouwd door zichzelf tot baas verheven hebbend OS + ontwikkelsoftware terwijl het wel gewoon een tundamentele operatie is en de machine is ontworpen om die uit te voeren.
Dit is geen security-issue maar het wegnemen van autoriteit die de fysieke gebruiker van een computer had sinds de 1e computers. "Memory-safe" kan zogenaamd alleen maar feit worden als bare-metal operatie van de hardware kunstmatig onbereikbaar is gemaakt. Een ontwikkelaar die bij alle knoppen kan is blijkbaar een probleem. Dit werk-niveau is te hoog gegrepen voor plebs.

[Reactie gewijzigd door blorf op 4 november 2025 14:25]

[Ebbez]

GNU is een collectie applicaties "bruikbaar als besturingssysteem", en MIT is een licentie. Een betere vergelijking zou Debian uutils/Linux zijn.

[AnonymousGerbil]

Tsjah, van canonical was, dacht ik, toch wel bekend dat die vernieuwingen doorvoert die soms nog niet echt van de kwaliteit zijn die men bij een grote distributie mag verwachten. Zelfs bij lts uitgaves.

Iets waarvan debian niet beschuldigd kan worden.

[Lethalis]

Tsja, als gebruiker merk je daar waarschijnlijk weinig van... als het blijft werken.

Hoogstens dat ik als programmeur denk dat ik misschien toch meer met Rust moet doen.

[morphje]

ALS het blijft werken. En daar zit momenteel de crux, de rust evangelisten proberen bestaande, stabiele tools uutils, apt, etc te converteren naar Rust in plaats van hun plaats te bewijzen met nieuwe tools. Zoveel zelfs dat de uutils in Ubuntu 25.01 veel unittests falen, wat niet echt bijdraagt aan het beeld van Rust. Er gaan ook veel dingen fout met Rust, er zijn meer dat 1 gedocumenteerde gevallen bekend waarin het toch niet zo heel memory safe bleek te zijn. Het is simpelweg een nieuwe taal en die moet zich nog bewijzen.

Systemd, al dan niet controversioneel, heeft een flinke aanloop gehad, maar heeft zich wel bewezen in de Linux wereld. Maar dat neemt niet weg dat ze hebben moeten vechten en zich moeten bewijzen voor die positie. De Linux kernel kan worden uitgebreid met Rust, maar het gaat voorlopig niet C vervangen.

Rust (en een paar andere Linux projecten) wordt nu evangelistisch opgedrongen en ze accepteren geen parallele wereld. Het gaat in tegen de principes van Linux en het draagt niet bij aan het beeld dat men heeft van Linux. Het helpt ook niet dat deze maintainer er eentje van Canonical is en die hebben een handje van evangelistisch doordrukken. Upstart, Mir, Snap, het zijn allemaal projecten die geen tractie krijgen, maar nu heeft een Canonical z'n voeten in de deur gekregen met apt en daar maken veel mensen (veelal terecht) zorgen om.

[Lethalis]

Systemd... brrr Ik ben nog steeds geen fan ervan hoe alles systemd dependencies lijkt te hebben. Laatst heeft een Fedora installatie van mij zelfmoord gepleegd tijdens het updaten, omdat hij tijdelijk geen internet had en daardoor half bijgewerkt was.

Ik kon niet eens een Gnome terminal starten zonder systemd errors te krijgen. Maar goed, ik heb doorgaans meer vertrouwen in Debian dan in Ubuntu. Wat daar gebeurt is inderdaad bizar... software die tests faalt gewoon releasen. Ach ja.

[uiltje]

In a followup message it seems that many ports already have this requirements:

Rust is already a hard requirement on all Debian release
architectures and ports except for alpha, hppa, m68k, and
sh4 (which do not provide sqv).

So these are all legacy archicectures. DEC Alpha is a 64 bit RISC, one of the first. HP PA-RISC is a Hewlett Packard (i.e. HP) 32 and later 64 bit instruction set supported until year 2k. Motorola 68000 is of course a more well known instruction set that features many computers until the switch to PowerPC in 1994 and finally SH4 is an instruction set from Renesas computers that was e.g. used in the Sega Saturn.

SQV is the Stable Quality Vector, i.e. the requirements you must meet to be considered to be a release architecture, i.e. that are qualified for stable releases.

[Reactie gewijzigd door uiltje op 3 november 2025 16:03]

[beerse]

Een mooi overzicht van deze oudere architecturen ten opzichte van de huidige ontwikkelingen. Het doet mij beseffen dat deze architecturen 30 jaar geleden nog wel een actuele waarde hadden maar ook al een gewis einde. De Intel Itanium architectuur was voor een aantal van deze wel gezien als een opvolger.

Voor mij zelf is het al weer 20 jaar geleden dat ik op een hp-pa-risc systeem een gentoo installatie heb uitgevoerd, om te kijken of dat kan. Natuurlijk is het leuk "omdat het kan" en is het de sport om het in gang te houden. Maar ondertussen vraag ik mij wel af waar deze systemen nog voor gebruikt worden, anders dan 'omdat het kan'. Mijn hp-pa-risc systemen zijn jaren geleden al afgevoerd.

[_Thanatos_]

Wat betekent die verplichting nou precies? Zijn distro's met een oudere versie van apt dan illegaal ofzo?

(er vanuit gaande dat Debian devs dan zelf apt gaan updaten met Rust support, en niet gaan vingertjewijzen naar devs die zich toewijden aan apt).