ZycordDokuEinen Download verifizieren

Einen Download verifizieren

Ein reproduzierbarer Build behauptet dies stammt aus diesem Quellcode, und jeder kann das prüfen — das ist die Zusicherung, die ein anonym veröffentlichtes Projekt anstelle eines Zertifikats zur Codesignatur bieten kann. So lösen Sie sie ein.

Drei Prüfungen, und sie beantworten unterschiedliche Fragen. Führen Sie sie in dieser Reihenfolge aus; jede ist weniger wert ohne die davor.

Prüfung	Was sie belegt	Was sie nicht belegt
Prüfsumme	Die Datei wurde auf dem Transportweg nicht verändert.	Irgendetwas darüber, wer sie erzeugt hat oder was darin steckt.
Signatur	Die Prüfsummenliste stammt vom Inhaber des Projektschlüssels.	Dass der Schlüssel jemandem gehört, dem zu vertrauen Sie Grund haben.
Nachbau	Die Binärdatei enthält diesen Quellcode und sonst nichts.	Dass der Quellcode ehrlich ist — lesen Sie ihn, oder lesen Sie die Reviews.

Die Prüfsumme#

curl -fsSLO https://zycord.com/releases//download/v<version>/SHA256SUMS.randomx
sha256sum --check --ignore-missing SHA256SUMS.randomx

# on macOS:
shasum -a 256 --check --ignore-missing SHA256SUMS.randomx

--ignore-missing ist nicht optional und keine Nachsicht

Releases liefern inzwischen nur noch die -randomx-Archive aus, also ist SHA256SUMS.randomx die Liste, die abdeckt, was Sie heruntergeladen haben; SHA256SUMS.deb und SHA256SUMS.desktop decken die Debian-Pakete und die Desktop-Wallet ab. Jede deckt mehrere Dateien ab, und Sie haben eine heruntergeladen. Ohne das Flag werden die fünf, die Sie nicht haben, als FAILED open or read gemeldet, und der Befehl endet bei einem völlig einwandfreien Download mit einem Fehlerstatus —

Die Signatur#

Es ist noch keine Signatur veröffentlicht, und dieser Abschnitt beschreibt das Vorgehen für den Fall, dass es eine gibt

Releases liefern derzeit zycord-release-key.asc aus — den öffentlichen Schlüssel —, aber nichts damit Signiertes außer dem Manifest des Updaters: keine der Prüfsummendateien hat eine abgetrennte Signatur, und keine ist klartextsigniert. Das gpg --verify weiter unten schlägt daher heute mit einer fehlenden Datei fehl, und das ist eine Lücke des Releases und nicht Ihr Fehler. Solange sie nicht geschlossen ist, ist die Prüfung, die das Vertrauensargument tatsächlich trägt, der Nachbau: er braucht überhaupt keine Signatur, weil Sie die Bytes selbst erzeugen und vergleichen.

Wenn eine Prüfsummensignatur veröffentlicht wird, wird sie mit dem Projektschlüssel erstellt. Der vollständige Fingerabdruck lautet:

E724 39CE DD85 11F9 D607 550B 87FD 60D5 EB4A 0B29

Er ist im Whitepaper-Kopf, in der archivierten Hinterlegung und in der Genesis-Ankündigung veröffentlicht. Er wird nie stillschweigend ausgetauscht: ein Schlüssel, der sich ohne eine signierte Erklärung des alten ändert, ist von einer Kompromittierung nicht zu unterscheiden und sollte als eine behandelt werden.

Der Fingerabdruck ist der Anker, nicht die Schlüsseldatei

Holen Sie sich den Schlüssel, woher es Ihnen passt, und prüfen Sie dann das Erhaltene gegen die Zeile oben. Eine Schlüsseldatei, deren Fingerabdruck dieser ist, ist der Projektschlüssel, ganz gleich, welcher Host sie Ihnen gereicht hat, und eine, deren Fingerabdruck ein anderer ist, ist wertlos, so vertrauenswürdig der Host auch aussah.

Drei Stellen führen ihn. Jede davon genügt:

# 1. The repository, if you have a clone. No network, no keyserver.
gpg --import packaging/zycord-release-key.asc

# 2. The release page, as an asset beside the archives.
curl -fsSLO https://zycord.com/releases//download/v<version>/zycord-release-key.asc
gpg --import zycord-release-key.asc

# 3. A keyserver. Use this one.
gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys E72439CEDD8511F9D607550B87FD60D5EB4A0B29

Bestätigen Sie dann, was in Ihren Schlüsselbund gelangt ist, bevor Sie sich darauf verlassen:

gpg --fingerprint E72439CEDD8511F9D607550B87FD60D5EB4A0B29

Verwenden Sie keys.openpgp.org nicht für diesen Schlüssel

Er ist in mehreren GnuPG-Builds der Standard-Keyserver, und er liefert eine beschnittene Kopie aus: das bloße Public-Key-Paket, ohne User-ID und ohne Selbstsignatur. GnuPG weist diese Kopie ab — gpg: key 87FD60D5EB4A0B29: new key but contains no user ID - skipped — und der Schlüssel gelangt nie in den Schlüsselbund, sodass die Prüfung unten mit dem fehlschlägt, was wie eine fehlerhafte Signatur aussieht und in Wahrheit ein fehlender Schlüssel ist. Dieser Server entfernt User-IDs grundsätzlich, bis eine Adresse über ihn bestätigt wurde, was ein pseudonymes Projekt nicht leisten kann.

gpg --verify SHA256SUMS.randomx.asc SHA256SUMS.randomx

Heute meldet das No such file or directory, weil noch kein Release diese Datei veröffentlicht hat. Siehe den Hinweis am Anfang dieses Abschnitts.

gpg wird ergänzen, dass der Schlüssel nicht mit einer vertrauenswürdigen Signatur zertifiziert ist. Das ist zu erwarten und kein Fehlschlag. Es heißt, dass Sie Ihrem Schlüsselbund nicht mitgeteilt haben, dass Sie persönlich für diesen Schlüssel einstehen, und genau dafür ist der Fingerabdruck da. Worauf es ankommt, ist, dass die Signatur aufgeht und dass der Schlüssel, gegen den sie geprüft wurde, der oben abgedruckte Fingerabdruck ist.

Das Whitepaper ist ebenfalls signiert#

Das von dieser Website ausgelieferte PDF hat eine abgetrennte Signatur daneben, mit demselben Schlüssel erstellt:

curl -fsSLO https://zycord.com/assets/zycord-whitepaper.pdf
curl -fsSLO https://zycord.com/assets/zycord-whitepaper.pdf.asc
gpg --verify zycord-whitepaper.pdf.asc zycord-whitepaper.pdf

Der Nachbau — die Prüfung, die ein Zertifikat tatsächlich ersetzt#

Ein Hash sagt Ihnen, dass die Datei auf dem Transportweg nicht verändert wurde. Er sagt nichts darüber, was der Herausgeber hineingelegt hat. Dies schon:

git clone https://gitlab.com/zycord-group/zycord-node.git
cd zycord-node
git checkout v<version>
make build
sha256sum bin/zcd bin/zycordd

Vergleichen Sie mit SHA256SUMS.binaries aus dem Release. Sie müssen exakt übereinstimmen. Tun sie das, enthält die heruntergeladene Binärdatei diesen Quellcode und sonst nichts — eine Behauptung, die noch nie ein Zertifikat über irgendetwas aufgestellt hat.

Die Go-Toolchain gehört zu dem, was Sie reproduzieren#

Es ist go1.26.2. Derselbe Quellcode, von zwei verschiedenen Go-Releases übersetzt, ergibt zwei verschiedene Binärdateien; das ist keine Feinheit, es ist messbar — der Release-Workflow dieses Repositorys hat schon einmal drei verschiedene SHA-256-Werte für einen Commit und einen Satz Flags aufgezeichnet, einen je Go-Version. Deshalb fixiert make build GOTOOLCHAIN=go1.26.2 und bricht mit einer Erklärung ab, wenn es diese Toolchain nicht verwenden kann, statt eine Abweichung zu erzeugen, die aussieht wie die Manipulation, für deren Erkennung diese ganze Seite da ist.

Zwei erfreuliche Folgen daraus:

Sie müssen der oben genannten Version nicht vertrauen. Die veröffentlichte Binärdatei nennt sie: go version -m zcd gibt die Toolchain aus, die sie gebaut hat, neben dem Modul und den Build-Flags. Sollten diese Zeile und die Fixierung im Makefile je auseinandergehen, wurde die Binärdatei nicht so gebaut, wie diese Seite es sagt.
Ein älteres Tag auszuchecken checkt seine Fixierung zusammen mit seinem Quellcode aus, sodass der Nachbau eines alten Releases weiter funktioniert, nachdem das Projekt auf ein neueres Go umgestiegen ist.

Zeilenenden sind hier Teil des Quellcodes#

wallet/webui bettet das Wallet-Frontend mit //go:embed ein, sodass die Zeilenenden dieser Dateien Bytes in der Binärdatei sind: ein auf CRLF umgestellter Checkout baut aus demselben Commit ein anderes zcd — eine Abweichung mit harmloser Ursache und beängstigendem Erscheinungsbild. Eine .gitattributes mit * text=auto eol=lf liefert LF im Arbeitsbaum auf jeder Plattform und bei jeder Git-Konfiguration, sodass ein frischer Klon überall dieselbe Antwort gibt.

Zwei Fälle deckt das nicht ab: den Nachbau eines Tags, das älter ist als diese Datei (setzen Sie dafür core.autocrlf=input vor dem Auschecken), und einen bestehenden Klon, der mit core.autocrlf=true angelegt wurde und beim Pull nicht von selbst heilt.

Die -randomx-Archive sind konstruktionsbedingt nicht reproduzierbar

RandomX ist C++, ein cgo-Build trägt also eine System-C-Toolchain in die Ausgabe, und niemand kann ihn Byte für Byte nachbauen. Diese Archive sind durch SHA256SUMS.randomx prüfsummiert und fehlen bewusst in SHA256SUMS.binaries, das auflistet, worauf ein Build hashen sollte, den Sie selbst aus dem Quellcode machen. Das ist die eine Stelle, an der die Stufe, die einem Netzwerk beitritt, und die Stufe, die attestiert ist, sich nicht überschneiden — siehe die Zwei-Stufen- Tabelle unter Installation. Es auszusprechen ist der Punkt: es ist Ihre Entscheidung statt einer Annahme, die für Sie getroffen wurde.

Die Implementierung gegen das Protokoll prüfen#

Unabhängig davon, die Herkunft einer Binärdatei zu prüfen, können Sie prüfen, ob sie das Protokoll umsetzt. Die Golden Vectors sind das Protokoll; eine unabhängige Implementierung, die sie besteht, ist ein Peer, kein Fork.

zcd vectors            # check this build against spec/vectors
zcd genesis --testnet  # rebuild block 0 and print its id
zcd params --testnet   # print the frozen parameters

zcd genesis ist der Befehl, auf den es am meisten ankommt: eine Launch-Ankündigung legt sich Wochen im Voraus auf das Code-Tag, den Parameter-Hash und die Genesis-ID fest — und dies baut sie alle in Millisekunden aus dem Quellcode auf jedem Rechner nach. Die Werte des öffentlichen Testnets stehen auf der Testnet-Seite; ein Build, der andere ausgibt, ist ein Build auf einer anderen Chain, und er wird sich nicht verbinden.

Unabhängige Attestierungen#

Eine Person, die ein Tag nachbaut, belegt, dass das Tag reproduzierbar ist. Mehrere Fremde, die es nachbauen und das Ergebnis signieren, belegen deutlich mehr, und es ist das Muster, auf das ernsthafte Projekte genau aus diesem Grund zugelaufen sind. Bauen Sie ein Tag nach und posten Sie den erhaltenen Digest und das gebaute Tag im Ankündigungs-Thread — auch dann, wenn er nicht übereinstimmt, denn das ist der Fall, von dem man hören will.