Windows-Installer von ImageMagick werden künftig nicht mehr signiert
(github.com/ImageMagick)- ImageMagick gab bekannt, dass das bisherige Code-Signing-Zertifikat am 28. Oktober 2023 abläuft und das bislang von LeaderSSL gesponserte Zertifikat nicht mehr bereitgestellt werden kann
- Seit Juni 2023 verlangt das CA/B Forum, dass private Schlüssel für OV-Code-Signing in einem nach FIPS 140-2 Level 2 oder Common Criteria Level EAL4+ zertifizierten Gerät gespeichert werden; damit ist der bisherige Weg blockiert, den privaten Schlüssel zu exportieren und in GitHub Actions zu verwenden
- Die Auswirkungen beschränken sich nicht nur auf
.exe-Installer, sondern betreffen alle Binärdateien, die mit dem Code-Signing-Zertifikat signiert wurden - In der Diskussion wurden Alternativen wie ein Zertifikat von DigiCert für 629 US-Dollar pro Jahr, SignPath, Azure Key Vault mit AzureSignTool, Azure Code Signing und Selbstsignierung genannt; einige davon haben Einschränkungen wie GitHub-Actions-Integration oder AppVeyor-Anforderungen
- ImageMagick entschied sich am 6. November 2023 für Azure Code Signing und konnte dadurch die Binärdateien wieder signieren
Ablauf des Zertifikats und Problem der eingestellten Signierung
- Der Maintainer von ImageMagick teilte mit, dass das derzeit verwendete Code-Signing-Zertifikat am 28. Oktober 2023 abläuft
- Über mehrere Jahre hatte LeaderSSL das Code-Signing-Zertifikat gesponsert, kann dies nun aber nicht mehr tun
- Seit Juni 2023 gelten geänderte Anforderungen des CA/B Forum: Private Schlüssel für OV-Code-Signing müssen in einem der folgenden Geräte gespeichert werden
- einem nach FIPS 140-2 Level 2 zertifizierten Gerät
- einem nach Common Criteria Level EAL4+ zertifizierten Gerät
- Aufgrund dieser Anforderung kann ImageMagick den bisherigen Ansatz, das Code-Signing-Zertifikat samt privatem Schlüssel zu exportieren und in GitHub Actions zu verwenden, nicht weiter nutzen
Benötigte Alternativen und Kosten
- Der Maintainer nannte zwei Optionen für ein neues Verfahren
- Nutzung eines eigenen GitHub-Agents mit Hardware-Token
- Nutzung einer in GitHub integrierten Cloud-basierten Signierlösung
- Bevorzugt wird eine Cloud-Lösung, die sich in GitHub integrieren lässt
- Der Maintainer sagte damals, DigiCert scheine die einzige Option zu sein; ein DigiCert-Code-Signing-Zertifikat koste für ein einzelnes Jahr 629 US-Dollar, zuzüglich Steuern
- Wenn Organisationen signierte Installer benötigen, bat er darum, ein Code-Signing-Zertifikat zu sponsern
Auswirkungen
- Ein Teilnehmer fragte, ob nur die
.exe-Installer betroffen seien oder ob auch alle Win32-Binärdateien wiemagick.exeim Portable-Zip nicht mehr signiert würden - Der Maintainer antwortete, dass alle Binärdateien betroffen seien, die mit dem Code-Signing-Zertifikat signiert wurden
Diskutierte Alternativen
-
SignPath
- Ein Teilnehmer schlug SignPath vor; der Maintainer kannte das Unternehmen nicht, antwortete aber, es könne eine Option sein
- Ein anderer Teilnehmer berichtete, er nutze SignPath seit mehr als zwei Jahren in einem OSS-Projekt und habe auf Fragen stets gute Antworten erhalten
- Derselbe Teilnehmer ergänzte, dass wegen der Herkunftsprüfung von SignPath für den Build signierter Binärdateien oder Installer AppVeyor erforderlich sei und Installer seines Wissens im
.MSI-Format vorliegen müssten - Ein Teilnehmer von SignPath erklärte, dass es beim kostenlosen Zertifikat einige Einschränkungen gebe
- Das kostenlose Zertifikat, das an die „SignPath Foundation“ ausgestellt wird, erfordert transparente und verifizierbare Builds; damals bedeutete das AppVeyor
- Ein Connector für GitHub Actions solle bald verfügbar sein
- Standardformate wie MSI, MSIX und AppX böten Vorteile, andere Installer könnten aber ebenfalls verarbeitet werden
- Da ImageMagick über eine registrierte LLC verfüge, könne ein Zertifikat auf den Namen ImageMagick ohne Einschränkungen ausgestellt werden; SignPath bot an, das erste Jahr zu sponsern
-
Azure Key Vault und AzureSignTool
- Ein Teilnehmer berichtete, er lege ein von GlobalSign ausgestelltes EV-Code-Signing-Zertifikat in Azure Key Vault ab und signiere Dateien in GitHub Actions mit AzureSignTool
- Der Maintainer antwortete, dies wirke wie eine günstigere Option, und erwähnte, dass ihm am Vortag auch dotnet/sign empfohlen worden sei, das
AzureSignToolnutzt - Ein weiterer Teilnehmer teilte einen Artikel darüber, wie man mit GlobalSign und Azure Key Vault Windows-Installer mit einem EV-Zertifikat signiert
- Ein Teilnehmer sagte, Azure Key Vault unterstütze dies, und selbst wenn man mehrmals täglich Builds signiere, lägen die Kosten nur im Cent-Bereich
- Später ergänzte ein anderer Teilnehmer, er habe nach Ablauf seines Zertifikats im Januar 2024 dasselbe Problem gehabt; das neue Zertifikat müsse auf einem Gerät ausgestellt werden und könne nicht in Azure Key Vault übertragen werden
-
Azure Code Signing
- Ein Teilnehmer sagte, er sei zu Azure Code Signing migriert und werde versuchen, Microsoft und das zuständige Team zu kontaktieren
- Der Maintainer antwortete, er habe AzureCodeSigningTAP direkt per E-Mail kontaktiert
- Ein Teilnehmer, der sich als Azure-Code-Signing-Engineer vorstellte, sagte, GitHub Actions werde unterstützt, und bot an, bei Bedarf Kontakt aufzunehmen
-
Selbstsignierung
- Ein Teilnehmer fragte, ob erwogen worden sei, die Binärdateien selbst zu signieren und die Nutzer das öffentliche Zertifikat installieren zu lassen
- Der Maintainer antwortete, dies sei noch nicht in Betracht gezogen worden; man prüfe derzeit die in der Diskussion vorgeschlagenen Optionen
Endgültige Entscheidung
- Am 6. November 2023 bedankte sich der Maintainer für die vorgeschlagenen Optionen und teilte mit, dass man sich für Azure Code Signing entschieden habe
- Durch diese Entscheidung konnte ImageMagick die Binärdateien wieder signieren
- Der Einrichtungsprozess sei in einem Beitrag in einem separaten Repository dokumentiert: ImageMagick now uses Azure Code Signing
1 Kommentare
Meinungen auf Hacker News
Ich habe einen kostenlosen Open-Source-Videoplayer für E-Sport-Coaches entwickelt, und weil Nutzer bei der Erstinstallation eine Warnung umgehen müssen, bekomme ich immer wieder Beschwerden – ich kann den Schmerz also nachvollziehen.
Die Kosten für ein Zertifikat könnte ich zwar bezahlen, aber bei einem Projekt, das ich ohnehin schon mit Zeitaufwand kostenlos bereitstelle, möchte ich nicht auch noch Geld drauflegen.
Ein Dienst wie Let's Encrypt für Open-Source-Software wäre schön, aber aus Sicht von Microsoft oder Apple würde das wohl ihren Kerninteressen widersprechen, weil es Menschen aus dem Walled Garden der App Stores herausführen könnte.
Ich entwickle seit fast 25 Jahren Software, und es ist ziemlich bitter zu sehen, wie unter dem Namen „Sicherheit“ mein Eigentumsrecht an meinem Computer immer weiter abnimmt.
https://www.vodon.gg/
Die übliche Antwort lautet, dass Code-Signing-Zertifikate auf einen rechtlichen Identitätsnachweis abzielen, damit Personen, die Malware verbreitet haben, offline zur Verantwortung gezogen werden können oder Richtlinien möglich sind, die nur Software von einer bestimmten Publisher-Liste installieren lassen.
Domain-Validation-Zertifikate für HTTPS sollen dagegen nachweisen, dass jemand Kontrolle über einen DNS-Namen hat; das lässt sich mit automatisierten technischen Mitteln prüfen und ist nicht zwingend mit einer Offline-Identität verknüpft.
Let's-Encrypt-Zertifikate bestätigen, dass ein bestimmter Schlüssel offenbar von der Person kontrolliert wird, die einen bestimmten DNS-Namen kontrolliert; Code-Signing-Zertifikate wollen dagegen zusätzlich bestätigen, dass er offenbar von einem Vertreter einer bestimmten juristischen Person in einer bestimmten Rechtsordnung kontrolliert wird. Die Kosten, das sinnvoll zu verifizieren, sind daher deutlich höher.
Vielleicht stellt eine Regierung irgendwann eine Möglichkeit bereit, das zu automatisieren, aber die beiden Zertifikatstypen unterscheiden sich erheblich darin, was sie belegen und wie die Prüfung funktioniert.
Eine ausführlichere Diskussion dazu läuft bereits unter https://news.ycombinator.com/item?id=38056024
Wenn den Nutzern das wirklich so wichtig ist, sollten sie bereit sein, die Kosten mitzutragen; wenn nicht, sollte ein unsignierter Zustand auch kein Problem sein.
Wenn genügend Downloads zusammenkommen, scheint diese Warnung zu verschwinden.
Mit einem Mac hat man solche Sorgen weniger.
Die Kosten sind nicht das einzige Problem.
Ich habe das Signieren über einen automatischen Release-Workflow verwaltet.
https://github.com/technion/rustypwneddownloader/blob/main/....
Nach den neuen Regeln kann ich diesen Workflow nicht mehr verwenden, und ich finde es schwer nachvollziehbar, dass es eine Sicherheitsverbesserung sein soll, den Build auf meinen Desktop zu verlagern, einen Hardware-Signaturschlüssel zu verwenden und ihn auf eine weder automatisierte noch transparente Weise hochzuladen.
Erstens können als Datei gespeicherte private Schlüssel unbemerkt gestohlen werden, und dann bleibt nur noch der Widerruf.
Das ist der Hauptgrund für die HSM-Anforderung; Malware-Autoren machen so etwas schon seit einiger Zeit, und ein Widerruf ist aus mehreren Gründen schwierig und teuer.
Auch ein HSM kann gestohlen werden, aber dafür müsste jemand in ein Büro oder eine Wohnung einbrechen und physisch etwas mitnehmen, was man eher bemerken würde.
Auch Zugangsdaten für die HSM-Nutzung können gestohlen werden, lassen sich aber leicht und schnell ändern: Wenn man feststellt, dass die PIN per Keylogging abgegriffen wurde, kann man nach der Bereinigung des Vorfalls einfach die PIN ändern und muss das Zertifikat nicht widerrufen.
Zweitens kann automatisches Signieren in CI tatsächlich riskant sein.
Jeder, der Code in das CI-System pushen kann, kann Code in deinem Namen signieren lassen, ohne dass du es überhaupt bemerkst.
Weil der Schlüssel ständig online ist, ist es vorbei, wenn das CI-System gehackt wird; und selbst wenn nicht, führt CI viel beliebigen Code aus und wird nicht engmaschig überwacht, sodass jede Person, die Code einschleusen kann, zu einer Schwachstelle wird.
Wenn man lokal signiert, kann der Schlüssel bis zum Release-Zeitpunkt buchstäblich offline bleiben, und mit dem Besitzfaktor Schlüssel plus dem Wissensfaktor Zugangsdaten lässt sich eine Zwei-Faktor-Authentifizierung einrichten, was ziemlich sicher ist.
Nightly-Development-Builds, interne Tools und temporäre Binärdateien, die nicht nach außen gelangen dürfen, kann man kostenlos selbst signieren.
Ich speichere ein OV-.pfx-Zertifikat in GitHub-Actions-Secrets und verwende es auf dieselbe Weise.
Mein Zertifikat läuft im November 2024 ab, und ich habe noch nicht entschieden, was ich tun werde.
Schon als einzelner Entwickler und nicht als Unternehmen ein Zertifikat zu bekommen, war schwierig genug.
Am Ende sollte es trotzdem eine Geldfrage sein.
Mit dem im Original erwähnten cloudgehosteten HSM für 629 US-Dollar pro Jahr wäre es möglich, und wenn man diese Kosten trägt, kann man es mit denselben Befehlen wie signtool oder Set-AuthenticodeSignature in GitHub Actions zum Laufen bringen: https://docs.digicert.com/en/software-trust-manager/ci-cd-in...
Man hängt einfach einen Hardware-Key an einen kleinen SFF-/Atom-PC für etwa 100 Dollar.
Das Einzige, was sich ändert, ist, dass der Signierschritt aus der Cloud auf den lokalen Runner wandert.
Ob das aus Sicherheitssicht eine Verbesserung ist oder nicht, weiß ich nicht so recht.
Es ist erstaunlich, dass ein so wichtiges und weit verbreitetes Projekt wie ImageMagick nicht einmal 629 $ für etwas Grundlegendes wie Software-Signierung aufbringen kann.
Das ist ein deutliches Beispiel dafür, dass die Tech-Industrie die Open-Source-Projekte, von denen sie stark abhängt, finanziell nicht angemessen unterstützt.
Selbst wenn solche Projekte enormen Wert liefern, können sie oft nicht genug davon abschöpfen, um nachhaltig zu sein.
Das ist ein nüchterner Reminder, dass sich grundlegend ändern muss, wie wir Open-Source-Beiträge behandeln und bewerten.
Der Kern ist, ob es hier um Sicherheit geht oder darum, unter dem Ruf nach „Sicherheit“ einen Markt durchzusetzen, an dem man nur gegen Bezahlung teilnehmen kann.
Eigentlich müsste es doch eher umgekehrt sein.
629 $ sind kein Kleingeld.
Das ist etwas, das Microsoft im Windows-Ökosystem selbst geschaffen hat.
Nicht darum, Miete an Microsoft oder dessen Partner zu zahlen.
Mein Desktop-Texteditor KeenWrite signiert Windows-Binaries mit Wine, rcedit-x64.exe, osslsigncode und Shell-Skripten.
Zuerst fügt rcedit-x64.exe dem Binary Identifikationsinformationen hinzu.
https://gitlab.com/DaveJarvis/KeenWrite/-/blob/main/installe...
Danach wendet osslsigncode das Zertifikat an.
https://gitlab.com/DaveJarvis/KeenWrite/-/blob/main/scripts/...
Wie schon gesagt: Dass ein Open-Source-Projekt mit 0 Dollar Umsatz zahlen muss, um auf Windows verteilt zu werden, bedeutet für mich weniger Eigentum an meinem eigenen Computer.
Es muss inzwischen HSM-basiert sein.
Ich habe sowohl unter Windows als auch unter macOS die Hölle mit Application Signing erlebt, und es wird immer schlimmer.
Erstens sorgt das dafür, dass man am liebsten alles als Web-App anbieten möchte.
Browser bieten in vielerlei Hinsicht eine deutlich bessere Experience, und Sicherheit ist dort gut integriert, während 25 Jahre alte Betriebssysteme wirken, als würde Sicherheit nachträglich angeflanscht.
Intern bei Apple wird das niemanden kümmern, aber es wäre ziemlich witzig, wenn genau das zu einem Riss würde, der ihr Hardware- und Software-Monopol aufbricht.
Zweitens frage ich mich, warum ein Dritter solche Signaturen nicht als Service anbieten kann.
Technisch gibt es doch keine Begrenzung dafür, wie viele Apps ich signieren kann, oder?
Ich sehe auch nicht, warum es aus Nutzersicht ein Problem sein sollte, wenn das Zertifikat nicht auf meinen Namen lautet, sondern auf ABC Corp, dem das Betriebssystem vertraut.
Irgendwo in der Kette könnte man sicher widerrufen, aber technisch scheint es möglich zu sein, und ich frage mich, ob es irgendwo in einer EULA, der ich halb im Tran zugestimmt habe, ausdrücklich verboten ist.
Trotzdem bin ich mit dem Ergebnis wirklich zufrieden, und die Nutzer scheinen es auch zu sein.
Interessanterweise hat mir kürzlich jemand empfohlen, es auszuprobieren, und war ziemlich überrascht, als er erfuhr, dass ich der Hauptautor bin.
Wird in diesem Szenario einfach blind alles signiert? Dann ist das offensichtlich schlecht.
Die Alternative sind lange Prüf- und Audit-Prozesse, aber wenn doch etwas durchrutscht, trifft es weiterhin den Unterzeichner.
Wenn es nicht gerade um Gerätetreiber geht, nähern wir uns dem Punkt, an dem man für die Nutzung im clientseitigen Browser neu kompilieren kann.
Wir hatten in der Firma kürzlich dasselbe Problem und haben erst von den geänderten Anforderungen erfahren, als unser bisheriger Anbieter das Zertifikat nicht mehr erneuern konnte.
Es gibt inzwischen erstaunlich wenig Informationen dazu, wie Windows Code Signing eigentlich gemacht werden soll.
Ein physisches Gerät wollten wir nicht verwenden, und für ein vollständig remote arbeitendes Team ist das auch nicht realistisch.
Am Ende haben wir uns für Azure KeyVault zusammen mit Digicert entschieden.
Comodo, also Sectigo, gefällt mir nicht.
Es gibt wirklich wenig Informationen dazu, wie man diese Kombination tatsächlich zum Laufen bringt, und man muss etwa 600 $ ausgeben, bevor man überhaupt testen kann, ob es funktioniert.
Nach der Einrichtung funktionierte es gut.
Das neue Setup zum Signieren über Azure ist sicherer, als private Schlüssel im CI-System zu speichern.
Aber ich hätte nie gedacht, dass das Signieren von Windows-Apps schwieriger sein würde als das Signieren für macOS oder iOS.
Mission erfüllt.
Wie gesagt, es fehlt an Informationen, und das wäre sicher für viele Leute nützlich, mich eingeschlossen.
Ich frage mich, ob jemand SignPath (https://signpath.org) ausprobiert hat, das in einer der Antworten erwähnt wurde.
Auf der Website steht: „SignPath Foundation provides reliable code signing for Open Source projects.“
Wenn es ein legitimer Service ist, könnte das eine nützliche Option sein.
Derzeit wird die „Foundation“ vom Unternehmen SignPath betrieben, aber man sagt, man hoffe, dass die Foundation eines Tages wächst und unabhängig sowie von der Community betrieben wird.
Ich frage mich, wo „Developers, developers, developers!“ geblieben ist
Was man bei großen Tech-Unternehmen immer wieder sieht: Am Anfang wirkt alles gut, ein paar Jahre später sickert Korruption ein, und wenn sie lange genug durchhalten, werden sie am Ende zu parasitären Existenzen
Ein Unternehmen von der Größe Microsofts kann unmöglich nicht in der Lage sein, einen Weg zu schaffen, damit die freie und Open-Source-Welt, die es angeblich so unterstützt, ohne Umstände oder Kosten auf der eigenen Plattform veröffentlichen kann
Diese Reibung im Namen der Sicherheit hilft zufällig immer auch dem Umsatz
Ich wünschte, die Kosten für Signaturzertifikate würden insgesamt gesenkt
Höchstens etwa 10 Dollar wären angemessen
Für Spezialsoftware, die nur sehr wenige Menschen nutzen, lassen sich die aktuellen Kosten nicht rechtfertigen
Der einzige Grund, der mir einfällt, warum es so teuer sein muss, ist, dass der Betrag groß genug sein muss, damit der rechtmäßige Besitzer einer gestohlenen Karte ihn bemerkt
Das könnte an sich eine Art Verifikation des Autors sein
Wenn das so ist, könnte man nach drei Monaten doch einen Teil oder alles zurückerstatten
Selbst wenn es um Verifikation geht, scheint es kaum nötig, dafür jedes Jahr Geld zu verlangen; am Ende wirkt es wie Rent-Seeking
Der Store kostet, soweit ich mich erinnere, einmalig 19 $ und nicht wiederkehrend oder jährlich
Dieses Problem betrifft also nur die Verteilung außerhalb des Stores
Zertifikate sind teuer, weil Regierungen nicht digitalisiert sind und Kryptografie nicht richtig handhaben; deshalb ist viel manuelle Arbeit nötig, um den Besitz eines privaten Schlüssels mit einer rechtlichen Identität zu verknüpfen
Zertifizierungsstellen müssen Registrierungsdaten auf länderspezifischen Websites suchen, oft ohne API, Telefonate führen, Pass-Scans prüfen und Ähnliches erledigen
All das ist arbeitsintensiv und wird dadurch teuer
Es könnte deutlich günstiger werden, wenn Regierungen ihre eigene Public-Key-Infrastruktur betreiben und bei der Unternehmensregistrierung gleich einen privaten Schlüssel ausstellen würden, oder wenn Pässe einen privaten Schlüssel zum Signieren von Dokumenten enthielten
Leider gab es seit Langem keine Fortschritte, und die wenigen Länder, die mit nationalen Public-Key-Infrastrukturen experimentiert haben, haben es größtenteils wieder aufgegeben
Die USA haben außerhalb des Verteidigungsministeriums nie eine groß angelegte staatliche Public-Key-Infrastruktur versucht, weshalb US-Softwareunternehmen auch wenig Anlass sahen, Smartcards gut zu unterstützen
Mainstream-Betriebssysteme haben keine solide Unterstützung, und es fehlt an Standards
Dazu kommt der hohe operative Aufwand, den der Zertifikatskonsument Microsoft und das CA/Browser Forum den Zertifizierungsstellen auferlegen
Auch das kostet Geld
Die jährlichen Gebühren dienen dazu, die Kosten über die Zeit zu verteilen
Eine Zertifizierungsstelle hat bei der erstmaligen Ausstellung eines Zertifikats höhere Kosten als eine Jahresgebühr, aber wenn sie davon ausgeht, dass der Nutzer es mehrere Jahre verwendet, kommt sie über den Break-even und erzielt einen kleinen Gewinn
https://www.gnu.org/philosophy/right-to-read.en.html
Je länger ich lebe, desto mehr wird mir klar, dass RMS eine moderne Kassandra war