Zertifikate und Signierung von Freeware?

[Uwe Raabe]

Zitat von Harry Stahl:

es erscheint dann ein Passwortfenster, wo ich das Passwort eingeben muss

Dieses interaktive Signieren, bei dem der Benutzer ein Passwort eingeben, einen Knopf drücken oder seinen Fingerabdruck oder sein Gesicht präsentieren muss, ist für einen automatisierten Build-Prozess schlichtweg nicht durchführbar. Ohne die Möglichkeit einer automatischen Signierung durch einen Build-Agent auf einer virtuellen Maschine ist das für professionelle Softwareentwicklung einfach nicht zu gebrauchen.

Erfreulicherweise scheint sich ja bei VSoft in dieser Richtung was zu tun: https://en.delphipraxis.net/topic/12...&comment=96095

[Harry Stahl]

Zitat von Uwe Raabe:

Zitat von Harry Stahl:

es erscheint dann ein Passwortfenster, wo ich das Passwort eingeben muss

Dieses interaktive Signieren, bei dem der Benutzer ein Passwort eingeben, einen Knopf drücken oder seinen Fingerabdruck oder sein Gesicht präsentieren muss, ist für einen automatisierten Build-Prozess schlichtweg nicht durchführbar. Ohne die Möglichkeit einer automatischen Signierung durch einen Build-Agent auf einer virtuellen Maschine ist das für professionelle Softwareentwicklung einfach nicht zu gebrauchen.

Erfreulicherweise scheint sich ja bei VSoft in dieser Richtung was zu tun: https://en.delphipraxis.net/topic/12...&comment=96095

Also mich stört es kaum, da ich ja so oft nicht eine neue Programmversion herausgebe. Dann muss ich zweimal ein Passwort eingeben (z.B. Signierung der Exe und Signierung des Setup-Programms), das kostet mich vielleicht 4 Sekunden. Gleichzeitig wird es sicherer, weil Passwörter nicht in Batch-Dateien eingespeichert sind oder privat-keys irgendwo frei zugänglich im Dateisystem gespeichert sind.

Hängt also wohl mehr von den Gesamtumständen ab...

[Uwe Raabe]

Es hängt davon ab, ob man einen automatisches Build-System hat, bei dem man den Build-Prozess über einen Klick auf den Start-Button des jeweiligen Projekts auf einem Dashboard (eine Webpage) startet und eben nicht vor dem ausführenden Rechner sitzt und mal eben den USB-Stick einstecken kann.

Die physikalische Basis meines Build-Systems steht im Keller und hat nicht mal einen Bildschirm, eine Tastatur oder eine Maus. Selbst wenn, würde der Build-Prozess gar nicht interaktiv ablaufen, so dass ein manuelles Eingreifen gar nicht möglich wäre (zumindest nicht ohne erheblichen Aufwand).

[himitsu]

Jo, wenn ein automatisiertes System die Anwendung bereitstellt bereitstellen soll, dann ist es echt sowas blöd unbenutzbar.

'nen Roboter, der mit einen künstlichen Finger dran stupst.
https://www.youtube.com/watch?v=Q_3f6OC9p0s

Wenn diese Bereitstellung aber nur intern ist und für die Kunden es (seltener) manuell erstellt wird, dann könnte man es schon so (umständlich) machen.
Für das Interne könnte man ja schließlich auch ein SelfSigned-Zertifikat benutzen.

Zitat:

... steht im Keller und hat nicht mal einen Bildschirm, eine Tastatur oder eine Maus. Selbst wenn, würde der Build-Prozess gar nicht interaktiv ablaufen ...

So einen USB-Stick mit Taster/Fingerabdruck/..., denn könntest du bei dir lokal angesteckt haben und im Keller wird über einen virtuellen USB-Port via LAN drauf zugegriffen.

Aber eigentlich hatte ich mir sowas eher mal andersrum vorgestellt (und viele Andere auch),
also der Stick steckt irgendwo in einem Host/NAS/sonstwo und via LAN kann sich der oder können sich die Entwickler diesen auf einen virtuellen USB-Port bei sich durchschleifen ... jeweils Einer, wer ihn grade braucht.

[jaenicke]

Certum wurde ja schon verlinkt. Und dort gibt es auch eine Clouud Signierung. Da kann man ein Token am Handy freischalten und kann dann 2 Stunden lang ohne Eingabe signieren. Das ist ein Kompromiss. Ähnliche Lösungen gibt es wohl auch, bei denen man nicht so oft etwas bestätigen muss.

Gut daran ist, dass der Server Anzeichen für einen Missbrauch erkennen kann und selbst bei Bekanntwerden der Zugangsdaten das weitere Signieren problemlos unterbunden werden kann.

[Uwe Raabe]

Vincent Parrett von VSoft beschäftigt sich ja schon eine ganze Weile mit dem Thema (siehe Code Signing with USB Tokens). Es gibt offenbar Tokens, mit denen man automatisch signieren kann - man muss nur sein Zertifikat bei jemandem erwerben, der solche Tokens verwendet.

Problematisch scheint aber die Bereitstellung eines solchen Tokens über das Netzwerk zu sein. Man könnte nun das Token auf einem dedizierten Build-Agent bereitstellen, der dann exklusiv für das Signieren zuständig ist. Das hat allerdings den Nachteil, dass die zu signierenden Dateien auf diesen Agent transportiert werden müssen und nach der Signierung potentiell auch wieder zurück müssen. Diese Verzögerung möchte man sicher vermeiden.

An diesem Punkt setzt der aktuell von VSoft entwickelte Code-Signing-Server an, der in dem bereits weiter oben von mir verlinkten Post in der Englischen DP erwähnt wird. Zusammen mit einem geeigneten Token sollte das den von mir beschriebenen Anforderungen genügen.

Mein aktuelles Zertifikat (ohne Token) läuft noch bis April 2026. Ich gehe davon aus, dass sich bis dahin eine stabile Lösung herausgebildet hat. Bis dahin werde ich wohl auch meine aktuelle ESX-Server Umgebung auf eine Proxmox-basierte Lösung migriert haben. Da VSoft intern auch Proxmox im Einsatz hat, stehen die Chancen gut, dass es damit dann funktioniert.

[jaenicke]

Sinnvoller wäre es, wenn man es der signierten Datei ansehen könnte, ob sie ohne Passworteingabe signiert wurde (und damit potentiell gefährlicher ist) oder mit manueller Eingabe eines Passworts (so dass das Vertrauen entsprechend höher ist). Dann könnte man dementsprechend unterscheiden.