w64devkit sperrt Releases so, dass nicht einmal der Betreuer sie ändern kann

Serguey Asael Shinder21 September 2026, 08:012 Min. Lesezeit

Chris Wellons hat ein Jahr Änderungen an w64devkit zusammengefasst, der portablen C- und C++-Entwicklungsumgebung für Windows: https://nullprogram.com/blog/2026/09/20/. Das meiste davon ist Lieferkettenarbeit — und ein brauchbares Modell für jedes kleine Projekt, das Binärdateien ausliefert.

Alles ist signiert. Sämtliche EXE- und DLL-Dateien eines Releases tragen eine Codesignatur. Der Signaturschlüssel hat sich seinen Ruf bei Sicherheitssoftware mühsam erarbeitet — rund 300 Binärdateien je Release auf etwa 100.000 Rechnern ergaben Tausende eindeutiger Signaturen. Das dafür verwendete Werkzeug aas-sign hat inzwischen MSYS2 übernommen; es liegt den w64devkit-Releases bei.

Builds löst ein Tag-Push aus, und pushen kann nur der Betreuer. GitHub Actions signiert und erstellt das Release, jeder Schritt leitet sich aus dem Repository ab und nicht aus irgendetwas Lokalem.

Releases sind unveränderlich. Nach der Veröffentlichung sind die Artefakte gesperrt: Niemand — auch der Betreuer nicht — kann sie noch ändern, und am Ende der Artefaktliste steht eine Release-Attestierung. Der Zweck ist unverblümt benannt: Niemand, der später am Projekt mitwirkt, soll unbemerkt ein altes Release verändern können.

An der Werkzeugkette selbst ist das x64-Release nun multilib — es baut auch 32-Bit- Binärdateien, sodass das separate x86-Release nur noch für alte Hardware und alte Windows-Versionen existiert (Ziel Windows XP, SSE2 vorausgesetzt). Dafür -m32 nutzen oder besser die Werkzeuge mit dem Präfix i686-w64-mingw32, die die richtigen Schalter selbst setzen. GCC braucht bin/ dank eines kleinen Patches nicht mehr im PATH, um seine eigenen Werkzeuge zu finden, und lässt sich so aus Skripten mit absolutem Pfad aufrufen.

Und ein Detail, das jemandem einen Tag spart: Das COFF-Objektformat erlaubt 65.535 Abschnitte — modernes C++ überschreitet das in Debug-Builds voller Lambdas mühelos. Binutils war so gepatcht, dass es immer bigobj erzeugte; das brach Konsumenten, die es nicht lesen können, darunter der Linker der Go-Werkzeugkette, und einen Weg zurück gab es nicht. Jetzt wird nur bei Bedarf auf bigobj hochgestuft: Große Programme funktionieren, einfache Linker und Formaterkennungsskripte sehen weiterhin Standard-COFF.

Was das bedeutet

Unveränderlichkeit ist die billigste Lieferkettenmaßnahme, die niemand einschaltet. Eine Signatur beweist, wer gebaut hat; Unveränderlichkeit beweist, dass das Artefakt seither nicht ausgetauscht wurde. Letzteres schützt gegen die Kompromittierung genau jener Person, die signiert — das Szenario praktisch aller jüngeren Registry-Vorfälle — und es kostet eine Einstellung.

„Nur mein Tag-Push löst einen Build aus" nimmt den lokalen Rechner aus der Kette. Jedes auf einem Laptop gebaute Release hat diesen Laptop in seiner Vertrauensgrenze. Den Build auf einen Runner zu verlegen, der vom Repository ausgeht und von sonst nichts, ist das, was „aus dem Quelltext nachvollziehbar" für Fremde überhaupt erst bedeutbar macht.

Und der bigobj-Fall ist eine kleine Lehre über Voreinstellungen. Immer-an war richtig für das behobene Problem und falsch für alle nachgelagerten Konsumenten, die die Ausgabe nicht lesen konnten. Eine Voreinstellung, die sich der Eingabe anpasst — Standard-COFF, bis die Abschnittszahl mehr verlangt — bedient beide Gruppen. Dafür musste jemand bemerken, dass der Go-Linker Kollateralschaden war.