Signierte Auslieferung veröffentlichen

Die IT hat den Starter einmal mit seiner Projektdatei installiert; von da an liefert der Herausgeber täglich neue Versionen auf die Freigabe aus, und der Starter jedes Benutzers darf nur Dateien installieren, die der Herausgeber signiert hat.

• Wkl.Bootstrapper.exe /new-key <name> erzeugt einmalig den Lieferschlüssel des Herausgebers im Windows-Schlüsselspeicher des Benutzerkontos des Herausgebers und gibt seinen öffentlichen Teil aus.
• Der öffentliche Teil kommt in deliveryKey der Projektdatei, die die IT verteilt.
• tools\Export-ComRegistration.ps1 schreibt registration.json neben jeden COM-Server der Auslieferung.
• Wkl.Bootstrapper.exe /publish /key <name> schreibt delivery.json (jede Datei mit Größe und SHA-256) und ihre Signatur delivery.json.sig in die Quelle, nach der letzten Änderung der Auslieferung.

Der Lieferschlüssel signiert je Auslieferung eine kleine Datei; er ist nicht das Codesignaturzertifikat des Unternehmens, dessen Zahl an Signaturen begrenzt sein kann. Programme und Bibliotheken, die die Auslieferung mitbringt, werden wie bisher mit dem Firmenzertifikat signiert, wo die Anwendungssteuerung von Windows es verlangt.

Einmalig, auf dem Computer des Herausgebers, im Ordner eines Starters, der die Projektdatei hat:

.\Wkl.Bootstrapper.exe /new-key Contoso
# prints the public key, for example MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE...

Tragen Sie den ausgegebenen Text in die Projektdatei ein und geben Sie diese Datei der IT für die Erstinstallation:

{ "format": 2, "product": "Kasse", "deliveryKey": "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE...", "...": "..." }

Für jede Auslieferung, sobald alle Dateien in der Quelle liegen:

# for each COM server of the delivery (once per bitness folder); DllInstall for servers registering per user
pwsh -File tools\Export-ComRegistration.ps1 -Dll \\server\share\kasse\com\x86\Kasse.Interop.dll
pwsh -File tools\Export-ComRegistration.ps1 -Dll \\server\share\kasse\net\Kasse.Bridge.dll -Kind NetCom
 
# last step: sign what is in the source now
.\Wkl.Bootstrapper.exe /publish /key Contoso
# Kasse 3.2.1: 14 files in \\server\share\kasse\delivery.json, signed.

/publish liest Produkt, Quelle und Version aus der Projektdatei neben dem Starter (oder aus der, die /RUNCFG <file> nennt). Einen Schlüssel, der nicht zu deliveryKey passt, lehnt es ab.

Ein Starter mit deliveryKey installiert nie eine niedrigere Version als die höchste, die sein Benutzer je installiert hat (Code 52); eine ältere signierte Auslieferung, die jemand auf die Freigabe zurücklegt, wird also abgewiesen. Um bewusst zurückzukehren – Version 3.3.0 ist fehlerhaft, die Benutzer sollen wieder 3.2.1 verwenden –, legen Sie 3.2.1 in die Quelle und nennen die Version, die sie ersetzt:

.\Wkl.Bootstrapper.exe /publish /key Contoso /withdraw 3.3.0
# Kasse 3.2.1: 14 files in \\server\share\kasse\delivery.json, signed, withdraws 3.3.0.

Mehrere Versionen trennen Sie durch Kommas (/withdraw 3.3.0,3.3.1); nennen Sie jede Version oberhalb der ausgelieferten, die ein Benutzer installiert haben kann. Jede muss höher sein als die ausgelieferte Version. Die Liste steht unter der Signatur: Ohne den Lieferschlüssel kann niemand eine Version hinzufügen. Ein Benutzer, der inzwischen 3.4.0 installiert hat, wird von dieser Auslieferung nicht zurückgeführt.

• Veröffentlichen Sie zuletzt: Eine Datei, die nach /publish geändert wird, wird nicht installiert (Code 51), und die Benutzer behalten die installierte Version, bis die Auslieferung erneut veröffentlicht wird.
• /publish entfernt die alte Signatur, bevor es das neue Manifest schreibt, sodass ein Starter, der dazwischen liest, ein unsigniertes Manifest vorfindet und die installierte Version behält – nie eine alte Signatur neben einem neuen Manifest.
• Der private Schlüssel liegt nie in einer Datei, wird aber exportierbar erzeugt: Jedes Programm, das unter dem Windows-Benutzer des Herausgebers läuft, kann damit signieren und ihn exportieren. Verwenden Sie dieses Konto nur zum Veröffentlichen. Der Starter hat keinen Befehl zum Exportieren oder Sichern; geht der Schlüssel verloren, braucht es einen neuen Schlüssel und eine neue Projektdatei, die die IT verteilt.
• Die Signatur deckt die Dateien von files ab. Programme von actions laufen direkt aus der Quelle und werden nicht gegen delivery.json geprüft: Wer in die Quelle schreiben kann, kann sie ändern, und sie laufen mit den Rechten jedes Benutzers, der die Anwendung startet.
• Eine früher signierte Auslieferung bleibt gültig, ab 2.2.4 kehren die Starter mit ihr aber nicht zurück: Wer eine ältere signierte Auslieferung in die Quelle zurücklegt, erhält auf jedem Rechner mit einer höheren Version Code 52, und diese Benutzer behalten sie. Ein Benutzer, der nie eine höhere Version installiert hatte (ein neuer Rechner, ein neuer Benutzer), installiert die ältere Auslieferung. Schützen Sie den Schreibzugriff auf die Quelle.
• Der Vertrauensanker ist der Ordner des Starters mit seiner Projektdatei: Der Lieferschlüssel schützt eine Auslieferung nur, solange Benutzer bootstrapper.json nicht ändern können, etwa wenn die IT den Starter mit dem MSI unter „Programme“ installiert. Ein Starter samt Projektdatei auf der Freigabe oder im Profil lässt sich zusammen mit dem Schlüssel ändern.
• Export-ComRegistration.ps1 führt die Registrierung des Servers einmal auf dem Computer des Herausgebers aus, wobei jeder Schreibzugriff auf die Registrierungsdatenbank in einen temporären Schlüssel umgeleitet wird, und löscht diesen Schlüssel anschließend; die eigene Registrierung des Computers ändert sich nicht. Das Skript startet sich selbst in der PowerShell der Bitbreite des Servers neu. Es erfasst Server, die sich mit DllRegisterServer oder DllInstall registrieren (etwa WKL Forms Object Library), und .NET-Framework-Assemblys. Manche Windows-Komponenten (zum Beispiel scrrun.dll, msxml6.dll) registrieren sich auf andere Weise und lassen sich nicht erfassen. Bei einem Server, der über HKEY_CLASSES_ROOT schreibt, dem üblichen Weg von ATL und Visual Basic 6: Prüfen Sie, dass die geschriebene Tabelle seine CLSID-Schlüssel enthält, bevor Sie sie veröffentlichen.
• Ohne deliveryKey schreibt /publish ohne /key trotzdem delivery.json: Die Starter prüfen dann Größen und Hashes (Integrität), nicht den Herausgeber.

• Die Projektdatei
• Die neue Version der Anwendung konnte nicht geprüft werden (Code 51)
• Der Ordner der Anwendung bietet eine ältere Version an als die bereits installierte (Code 52)