Επαλήθευση εκδόσεων του Zcash
Με λίγα λόγια
- Η λήψη ενός binary του Zcash δεν σημαίνει ότι έχεις αυτό που δημοσίευσε το έργο. Η επαλήθευση είναι ο τρόπος να ξεχωρίσεις τη διαφορά.
- Ένα checksum αποδεικνύει ότι το αρχείο έφτασε άθικτο. Μια υπογραφή αποδεικνύει ποιος το παρήγαγε. Χρειάζεσαι και τα δύο, και ένα checksum από μόνο του αποδεικνύει πολύ λίγα.
- Το Zebra δημοσιεύει ένα αρχείο
SHA256SUMS μαζί με ένα πακέτο Sigstore που συνδέει την έκδοση με συγκεκριμένο workflow του GitHub Actions, tag και commit — χωρίς να απαιτείται διαχείριση κλειδιών.
- Το Zallet δημοσιεύει αποσυνδεδεμένες υπογραφές GPG (
.asc), μαζί με SLSA provenance και ένα SBOM.
- Το κλειδί υπογραφής του Zcash άλλαξε το 2026 από το Electric Coin Company στο Zcash Open Development Lab (ZODL). Αν επαλήθευσες παλαιότερες εκδόσεις, χρειάζεσαι το νέο κλειδί — και η δήλωση μεταβίβασης είναι υπογεγραμμένη και από τα δύο κλειδιά, ώστε να μπορείς να επαληθεύσεις και την ίδια την αλλαγή.
- Το
gpg αναφέρει το subkey που υπέγραψε ένα αρχείο, όχι το πρωτεύον κλειδί που αναφέρεται στις ανακοινώσεις. Ένα fingerprint που φαίνεται λανθασμένο είναι συνήθως subkey, όχι επίθεση.
- Αν η επαλήθευση αποτύχει, μην εκτελέσεις το binary.
Επαληθεύτηκε με το Zebra v6.3.0 και το Zallet v0.1.0-beta.2 στις 2026-08-18.
Γιατί αυτό έχει μεγαλύτερη σημασία για το Zcash
Ένα παραποιημένο binary πορτοφολιού μπορεί να εξάγει ένα spending key ή ένα viewing key. Σε αντίθεση με έναν παραβιασμένο κωδικό πρόσβασης, αυτή η απώλεια είναι μόνιμη: δεν υπάρχει αναίρεση, αντιλογισμός ή γραφείο υποστήριξης. Οι θωρακισμένες συναλλαγές προστατεύουν ό,τι συμβαίνει on-chain — δεν προσφέρουν καμία απολύτως προστασία όταν το λογισμικό που εκτελείς αντικαταστάθηκε πριν καν φτάσει σε εσένα.
Αυτή είναι μία από τις λίγες διαδρομές επίθεσης όπου οι εγγυήσεις ιδιωτικότητας του πρωτοκόλλου απλώς δεν είναι σχετικές. Η επαλήθευση είναι το επίπεδο που την καλύπτει.
Μοντέλο απειλών — τι εντοπίζει και τι δεν εντοπίζει η επαλήθευση
Εντοπίζει:
- Έναν παραποιημένο mirror ή ένα τροποποιημένο αρχείο που παρέχεται από κάπου διαφορετικά από τη σελίδα εκδόσεων του έργου.
- Ένα swap man-in-the-middle κατά τη λήψη.
- Ένα παραβιασμένο CDN ή έναν καταληφθέντα host διανομής.
- Τυχαία αλλοίωση κατά τη μεταφορά.
Δεν εντοπίζει:
- Έναν συντηρητή που υπογράφει κακόβουλο κώδικα. Η υπογραφή θα επαληθευτεί σωστά· αποδεικνύει την προέλευση, όχι την πρόθεση.
- Έναν παραβιασμένο host δημιουργίας που παράγει ένα υπογεγραμμένο αλλά κακόβουλο artifact. Αυτό είναι που υπάρχουν οι αναπαραγώγιμες δημιουργίες και οι βεβαιώσεις provenance για να περιορίζουν.
- Ένα κλειδί που απέκτησες από την ίδια παραβιασμένη πηγή με το binary. Αν ένας επιτιθέμενος ελέγχει τόσο το αρχείο όσο και το κλειδί με το οποίο το ελέγχεις, η επαλήθευση δεν σου λέει τίποτα.
Το τελευταίο σημείο είναι αυτό που οι περισσότεροι οδηγοί παραλείπουν. Το από πού αποκτάς το κλειδί έχει την ίδια σημασία με την εκτέλεση της εντολής.
Μέρος 1 — Zebra: checksums και Sigstore
Το Zebra δημοσιεύει αυτά τα στοιχεία για κάθε έκδοση:
| Στοιχείο | Σκοπός |
|---|
zebrad-<version>-<arch>.tar.gz | το αρχείο binary |
zebrad-<version>-<arch>.tar.gz.sha256 | checksum ανά αρχείο |
SHA256SUMS | checksums για όλες τις αρχιτεκτονικές |
SHA256SUMS.sigstore.json | πακέτο Sigstore που υπογράφει το SHA256SUMS |
Βήμα 1 — Λήψη
Code-highlight
BASE=https://github.com/ZcashFoundation/zebra/releases/download/v6.3.0
curl -sLO $BASE/zebrad-6.3.0-x86_64-unknown-linux-gnu.tar.gz
curl -sLO $BASE/SHA256SUMS
curl -sLO $BASE/SHA256SUMS.sigstore.json
Βήμα 2 — Έλεγξε το checksum
Code-highlight
sha256sum -c --ignore-missing SHA256SUMS
Πραγματικό αποτέλεσμα:
Code-highlight
zebrad-6.3.0-x86_64-unknown-linux-gnu.tar.gz: OK
Το --ignore-missing απαιτείται εδώ επειδή το SHA256SUMS καλύπτει κάθε αρχιτεκτονική και εσύ κατέβασες μόνο μία. Χωρίς αυτό, το sha256sum αναφέρει το απόν αρχείο aarch64 ως αποτυχία και μπορεί να διαβάσεις λανθασμένα μια επιτυχία ως αποτυχία.
Λειτουργεί επίσης η παραλλαγή ανά αρχείο:
Code-highlight
sha256sum -c zebrad-6.3.0-x86_64-unknown-linux-gnu.tar.gz.sha256
Code-highlight
zebrad-6.3.0-x86_64-unknown-linux-gnu.tar.gz: OK
Αυτό το βήμα από μόνο του δεν αρκεί. Κατέβασες το checksum από το ίδιο μέρος με το binary. Όποιος μπορούσε να αντικαταστήσει το ένα, μπορούσε να αντικαταστήσει και το άλλο. Το checksum αποδεικνύει την ακεραιότητα· το επόμενο βήμα αποδεικνύει την προέλευση.
Βήμα 2β — Ο ίδιος έλεγχος στο Windows
Το PowerShell δεν έχει λειτουργία επαλήθευσης του -c, οπότε συγκρίνεις χειροκίνητα:
Code-highlight
Get-FileHash .\zebrad-6.3.0-x86_64-unknown-linux-gnu.tar.gz -Algorithm SHA256 | Format-List
Πραγματικό αποτέλεσμα:
Code-highlight
Algorithm : SHA256
Hash : 86326F5324F4E59CC2008C15F94407CC8D5FEACF75D64942164BB5F08ECA8C5E
Path : \\wsl$\Ubuntu\home\briefking\verify\zebrad-6.3.0-x86_64-unknown-linux-gnu.tar.gz
Σύγκρινέ το με το αποτέλεσμα του Linux νωρίτερα σε αυτή τη σελίδα:
Code-highlight
86326f5324f4e59cc2008c15f94407cc8d5feacf75d64942164bb5f08eca8c5e
86326F5324F4E59CC2008C15F94407CC8D5FEACF75D64942164BB5F08ECA8C5E
Πανομοιότυπες τιμές. Το hexadecimal δεν διακρίνει πεζά και κεφαλαία, και αυτή είναι η συχνότερη ψευδής ειδοποίηση στο Windows.
Δύο ακόμη παγίδες ειδικές για το Windows:
- Δεν υπάρχει exit code για έλεγχο. Στο Linux, το
sha256sum -c επιστρέφει 1 σε περίπτωση αποτυχίας και ένα script μπορεί να ενεργήσει βάσει αυτού. Το Get-FileHash απλώς εκτυπώνει ένα hash — η σύγκριση είναι δική σου ευθύνη και είναι εύκολο να κάνεις λάθος αν το εξετάσεις βιαστικά.
- Η ανάγνωση 64 hexadecimal χαρακτήρων με το μάτι δεν είναι αξιόπιστη. Άφησε το shell να το κάνει:
Code-highlight
$expected = "86326f5324f4e59cc2008c15f94407cc8d5feacf75d64942164bb5f08eca8c5e"
$actual = (Get-FileHash .\zebrad-6.3.0-x86_64-unknown-linux-gnu.tar.gz -Algorithm SHA256).Hash.ToLower()
if ($actual -eq $expected) { "OK" } else { "MISMATCH" }
Στο macOS: η ροή εργασίας είναι η ίδια, αλλά το BSD userland παρέχει το shasum αντί για το sha256sum — χρησιμοποίησε το shasum -a 256 -c --ignore-missing SHA256SUMS. Ο συγγραφέας αυτής της σελίδας δεν είχε διαθέσιμο μηχάνημα macOS, επομένως αυτή η εντολή τεκμηριώνεται από τα εργαλεία της Apple αντί να έχει εκτελεστεί. Αν επαληθεύεις σε macOS, υπόβαλε ένα PR που να την επιβεβαιώνει ή να τη διορθώνει.
Βήμα 3 — Επαλήθευσε το πακέτο Sigstore
Το Sigstore αντικαθιστά τα μακρόβια κλειδιά υπογραφής με βραχύβια πιστοποιητικά συνδεδεμένα με μια ταυτότητα CI, καταγεγραμμένα σε δημόσιο transparency log. Κανείς δεν κατέχει ένα κλειδί έκδοσης που μπορεί να κλαπεί.
Η άμεση διαδρομή χρησιμοποιεί το cosign:
Code-highlight
cosign verify-blob \
--bundle SHA256SUMS.sigstore.json \
--certificate-identity-regexp '^https://github\.com/ZcashFoundation/zebra/' \
--certificate-oidc-issuer https://token.actions.githubusercontent.com \
SHA256SUMS
Τα δύο flags του --certificate-* είναι το ουσιαστικό σημείο. Χωρίς αυτά επιβεβαιώνεις μόνο ότι κάποιος, κάπου υπέγραψε το αρχείο. Με αυτά επιβεβαιώνεις ότι υπογράφηκε από workflow στο αποθετήριο Zebra, που πιστοποιήθηκε από τον OIDC issuer του GitHub.
⚠️ Η έκδοση έχει σημασία. Παλαιότερες εκδόσεις του cosign δεν μπορούν να διαβάσουν την τρέχουσα μορφή πακέτου Sigstore. Η εκτέλεση της παραπάνω εντολής με cosign v2.4.1 παράγει:
Code-highlight
Error: bundle does not contain cert for verification, please provide public key
Το πακέτο περιέχει πιστοποιητικό — βρίσκεται κάτω από το verificationMaterial.certificate.rawBytes, όπου οι παλαιότερες εκδόσεις δεν αναζητούν. Αυτός είναι περιορισμός του client, όχι κατεστραμμένη έκδοση. Αν το συναντήσεις, αναβάθμισε το cosign αντί να συμπεράνεις ότι η λήψη είναι κακή. Το cosign από πακέτα διανομών συχνά υστερεί σημαντικά από το upstream.
Τα επόμενα δύο βήματα δείχνουν πώς να επαληθεύσεις το ίδιο πακέτο χειροκίνητα, κάτι που αξίζει να κατανοήσεις ανεξάρτητα — και είναι μια λειτουργική εναλλακτική όταν η έκδοση cosign που έχεις δεν συνεργάζεται.
Βήμα 4 — Διάβασε τι ακριβώς δηλώνει το πιστοποιητικό
Μπορείς να επιθεωρήσεις το πακέτο χωρίς το cosign, κάτι χρήσιμο για να κατανοήσεις τι εμπιστεύεσαι. Εξήγαγε το πιστοποιητικό:
Code-highlight
python3 -c "
import json,base64
d=json.load(open('SHA256SUMS.sigstore.json'))
open('cert.der','wb').write(base64.b64decode(d['verificationMaterial']['certificate']['rawBytes']))"
openssl x509 -in cert.der -inform DER -noout -issuer -ext subjectAltName
Πραγματικό αποτέλεσμα για το Zebra v6.3.0:
Code-highlight
issuer=O = sigstore.dev, CN = sigstore-intermediate
X509v3 Subject Alternative Name: critical
URI:https://github.com/ZcashFoundation/zebra/.github/workflows/zfnd-release-binaries.yml@refs/tags/v6.3.0
Το Subject Alternative Name είναι η ταυτότητα. Κατονομάζει το αποθετήριο, το ακριβές αρχείο workflow και το tag. Το Sigstore ενσωματώνει επιπλέον μεταδεδομένα δημιουργίας σε προσαρμοσμένες επεκτάσεις:
| Πεδίο | Τιμή για v6.3.0 |
|---|
| OIDC issuer | https://token.actions.githubusercontent.com |
| Source repository | https://github.com/ZcashFoundation/zebra |
| Build commit | f5c5277fe41eba9c74f37098738f93f35dd70d60 |
| Ref | refs/tags/v6.3.0 |
| Runner environment | github-hosted |
| Workflow run | .../actions/runs/31424510487/attempts/1 |
| Repository visibility | public |
Καθένα από αυτά μπορεί να ελεγχθεί. Το hash του commit πρέπει να αντιστοιχεί στο tag στο αποθετήριο· η εκτέλεση workflow πρέπει να υπάρχει και να είναι δημόσια.
Βήμα 5 — Επαλήθευσε την υπογραφή κρυπτογραφικά
Μπορείς να επιβεβαιώσεις την υπογραφή απευθείας με OpenSSL:
Code-highlight
python3 -c "
import json,base64
d=json.load(open('SHA256SUMS.sigstore.json'))
open('sig.bin','wb').write(base64.b64decode(d['messageSignature']['signature']))"
openssl x509 -in cert.der -inform DER -pubkey -noout > pub.pem
openssl dgst -sha256 -verify pub.pem -signature sig.bin SHA256SUMS
Πραγματικό αποτέλεσμα:
Code-highlight
Verified OK
Το πακέτο καταγράφει επίσης το digest που υπέγραψε. Επιβεβαίωσε ότι αντιστοιχεί στο τοπικό σου αρχείο:
Code-highlight
bundle digest : 3eb5de0634f637e793d0411b6c7108802a36e1219f9151803ecc6108fd0f59f6
local digest : 3eb5de0634f637e793d0411b6c7108802a36e1219f9151803ecc6108fd0f59f6
Βήμα 6 — Η καταχώριση transparency log
Το πακέτο περιέχει μια καταχώριση Rekor που αποδεικνύει ότι η υπογραφή δημοσιεύτηκε σε δημόσιο append-only log:
| Πεδίο | Τιμή |
|---|
| Rekor log index | 2412071838 |
| Entry type | hashedrekord v0.0.1 |
| Integrated at | 2026-08-10 19:43:09 UTC |
Αυτό είναι που καθιστά ανιχνεύσιμη τη σιωπηλή κατάχρηση κλειδιού. Μια υπογραφή που δεν εμφανίστηκε ποτέ στο log ή εμφανίστηκε σε απίθανη χρονική στιγμή είναι σήμα στο οποίο αξίζει να ενεργήσεις. Σύγκρινε τον χρόνο ενσωμάτωσης με την ανακοίνωση της έκδοσης.
Σημείωση για τη διαδρομή OpenSSL: επαληθεύει την υπογραφή έναντι του δημόσιου κλειδιού του πιστοποιητικού, αλλά δεν επικυρώνει από μόνη της την αλυσίδα πιστοποιητικών έως το root του Sigstore ούτε ελέγχει την απόδειξη συμπερίληψης της καταχώρισης log. Το cosign verify-blob κάνει και τα τρία. Χρησιμοποίησε το OpenSSL για να κατανοήσεις τον μηχανισμό· χρησιμοποίησε το cosign ως τον πραγματικό έλεγχό σου.
Μέρος 2 — Zallet: υπογραφές GPG
Το Zallet δημοσιεύει ένα διαφορετικό σύνολο στοιχείων:
| Στοιχείο | Σκοπός |
|---|
zallet-<version>-<platform>.tar.gz | το αρχείο binary |
.tar.gz.asc | αποσυνδεδεμένη υπογραφή GPG |
.tar.gz.intoto.jsonl | βεβαίωση SLSA provenance |
.tar.gz.provenance.json | μεταδεδομένα provenance |
.tar.gz.sbom.spdx | κατάλογος υλικών λογισμικού |
Βήμα 1 — Ταυτοποίησε το κλειδί υπογραφής πριν αρχίσεις να το αναζητάς
Εκτέλεσε την επαλήθευση πρώτα, χωρίς να έχεις εισαγάγει κλειδί:
Code-highlight
gpg --verify zallet-v0.1.0-beta.2-linux-amd64.tar.gz.asc \
zallet-v0.1.0-beta.2-linux-amd64.tar.gz
Πραγματικό αποτέλεσμα:
Code-highlight
gpg: Signature made Tue Jul 28 19:18:44 2026 WAT
gpg: using RSA key 1FE99324758F296718B457067F4BBBBA23F0617F
gpg: issuer "sysadmin@zodl.com"
gpg: Can't check signature: No public key
Αυτό δεν είναι αποτυχία. Σου λέει ότι υπάρχει υπογραφή και κατονομάζει ακριβώς το κλειδί που χρειάζεσαι, πριν αρχίσεις την αναζήτηση. Σημείωσε το fingerprint και τον issuer, έπειτα απόκτησε το κλειδί από πηγή ανεξάρτητη από τη λήψη.
Το gpg εκτυπώνει timestamps στη δική σου τοπική ζώνη ώρας. Το παραπάνω αποτέλεσμα δείχνει το WAT (UTC+1)· η ίδια υπογραφή εμφανίζεται ως 18:18:44 UTC αλλού. Η ίδια χρονική στιγμή. Μην αντιμετωπίζεις τη διαφορά ζώνης ώρας ως ασυμφωνία.
Βήμα 2 — Εισήγαγε το κλειδί και επαλήθευσε
Code-highlight
curl -sL https://apt.z.cash/zodl.asc -o zodl.asc
gpg --import zodl.asc
gpg --verify zallet-v0.1.0-beta.2-linux-amd64.tar.gz.asc \
zallet-v0.1.0-beta.2-linux-amd64.tar.gz
Πραγματικό αποτέλεσμα:
Code-highlight
gpg: Signature made Tue Jul 28 19:18:44 2026 WAT
gpg: using RSA key 1FE99324758F296718B457067F4BBBBA23F0617F
gpg: issuer "sysadmin@zodl.com"
gpg: Good signature from "Zcash Open Development Lab (ZODL) (Dallas, Texas) <sysadmin@zodl.com>" [unknown]
gpg: WARNING: The key's User ID is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 0338 34DD 49DE CF9D BB99 34BC 6C93 CA8E 58E2 6AB1
Subkey fingerprint: 1FE9 9324 758F 2967 18B4 5706 7F4B BBBA 23F0 617F
Το Good signature είναι αυτό που ήθελες. Δύο πράγματα σε αυτό το αποτέλεσμα μπερδεύουν τους ανθρώπους, και τα δύο είναι φυσιολογικά.
Γιατί το fingerprint δεν αντιστοιχεί στην ανακοίνωση
Η δήλωση μετάβασης κλειδιού του ZODL αναφέρει το fingerprint 0338 34DD 49DE CF9D BB99 34BC 6C93 CA8E 58E2 6AB1. Όμως το gpg --verify ανέφερε το 1FE9 9324 … 23F0 617F. Αυτό μοιάζει με ασυμφωνία, αλλά δεν είναι.
Το gpg αναφέρει το subkey που δημιούργησε την υπογραφή. Η ανακοίνωση αναφέρει το πρωτεύον κλειδί. Επιβεβαίωσε εσύ τη σχέση:
Code-highlight
gpg --list-keys --with-subkey-fingerprints sysadmin@zodl.com
Πραγματικό αποτέλεσμα:
Code-highlight
pub rsa4096 2026-03-23 [SCEA]
033834DD49DECF9DBB9934BC6C93CA8E58E26AB1
uid [ unknown] Zcash Open Development Lab (ZODL) (Dallas, Texas) <sysadmin@zodl.com>
sub rsa4096 2026-03-23 [SEA]
1FE99324758F296718B457067F4BBBBA23F0617F
Η γραμμή sub είναι το subkey υπογραφής· η γραμμή pub είναι το πρωτεύον. Μία ταυτότητα, ένα πακέτο κλειδιού. Αυτός είναι ο λόγος που το αποτέλεσμα επαλήθευσης εκτυπώνει και τα δύο fingerprints — σύγκρινε το πρωτεύον με κάθε δημοσιευμένη ανακοίνωση και αντιμετώπισε τη γραμμή subkey ως ένδειξη για το ποιο τμήμα του κλειδιού έκανε τη δουλειά.
Ο διαχωρισμός των κλειδιών με αυτόν τον τρόπο είναι σκόπιμος: ένα subkey υπογραφής μπορεί να αλλάξει ή να ανακληθεί χωρίς να απορριφθεί η πρωτεύουσα ταυτότητα και η συσσωρευμένη εμπιστοσύνη της.
Τι σημαίνει η προειδοποίηση του [unknown]
Code-highlight
gpg: WARNING: The key's User ID is not certified with a trusted signature!
Αυτό δεν είναι πρόβλημα με την υπογραφή. Η υπογραφή είναι κρυπτογραφικά έγκυρη — αυτό δηλώνει το Good signature. Η προειδοποίηση λέει κάτι διαφορετικό: δεν έχεις πει στο τοπικό σου GnuPG ότι πιστεύεις πως αυτό το κλειδί ανήκει σε εκείνον που ισχυρίζεται ότι είναι.
Το GnuPG διαχωρίζει δύο ερωτήματα:
- Υπέγραψε αυτό το κλειδί αυτό το αρχείο; — απαντάται από το
Good signature. Κρυπτογραφικό, χωρίς ανθρώπινη κρίση.
- Ανήκει αυτό το κλειδί στο ZODL; — δεν απαντάται καθόλου από την κρυπτογραφία. Το τεκμηριώνεις ελέγχοντας το fingerprint έναντι ανεξάρτητης πηγής.
Θα δεις αυτή την προειδοποίηση σχεδόν σε κάθε επαλήθευση, εκτός αν υπογράψεις ρητά το κλειδί τοπικά. Μην τη θεωρήσεις αποτυχία. Θεώρησε όμως την απουσία του Good signature αποτυχία.
Βήμα 3 — Επαλήθευσε την ίδια τη μετάβαση κλειδιού
Η υπογραφή εκδόσεων του Zcash μεταφέρθηκε από το Electric Coin Company στο Zcash Open Development Lab το 2026, αφού το ZODL σχηματίστηκε τον Ιανουάριο του 2026 από την πρώην ομάδα engineering και product του ECC.
| Παλιό κλειδί | Νέο κλειδί |
|---|
| Fingerprint | B1C9 095E AA18 48DB B54D 9DDA 1D05 FDC6 6B37 2CFE | 0338 34DD 49DE CF9D BB99 34BC 6C93 CA8E 58E2 6AB1 |
| UID | Zcash Master Signing Key (ECC) <sysadmin@z.cash> | Zcash Open Development Lab (ZODL) <sysadmin@zodl.com> |
| Τύπος | RSA 3072-bit, δημιουργήθηκε 2023-06-19 | RSA 4096-bit, δημιουργήθηκε 2026-03-23, λήγει 2028-03-22 |
| Δημοσιεύτηκε στις | https://apt.z.cash/zcash.asc | https://apt.z.cash/zodl.asc |
Δημοσιευμένο χρονοδιάγραμμα: νέο κλειδί δημιουργήθηκε στις 2026-03-23, ανακοινώθηκε στις 2026-03-27, αποκλειστική υπογραφή από τις 2026-04-23, ανάκληση του παλιού κλειδιού ECC προγραμματισμένη για τις 2026-06-23.
Μια ανακοίνωση αλλαγής σε ιστότοπο είναι τόσο αξιόπιστη όσο και ο ίδιος ο ιστότοπος. Ο σωστός μηχανισμός είναι μια δήλωση clear-signed και από τα δύο κλειδιά, ώστε το παλιό κλειδί να εγγυάται για το νέο. Το ZODL δημοσιεύει ακριβώς αυτό:
Code-highlight
curl -sL https://zodl.com/security/key-transition.txt.asc -o key-transition.txt.asc
curl -sL https://apt.z.cash/zcash.asc -o zcash.asc
gpg --import zcash.asc
gpg --verify key-transition.txt.asc
Πραγματικό αποτέλεσμα (συντομευμένο — δύο υπογραφές σε ένα έγγραφο):
Code-highlight
gpg: Signature made Fri Mar 27 01:11:14 2026 WAT
gpg: using RSA key B1C9095EAA1848DBB54D9DDA1D05FDC66B372CFE
gpg: issuer "sysadmin@z.cash"
gpg: Good signature from "Zcash Master Signing Key (Electric Coin Company) <sysadmin@z.cash>" [unknown]
Primary key fingerprint: B1C9 095E AA18 48DB B54D 9DDA 1D05 FDC6 6B37 2CFE
gpg: Signature made Fri Mar 27 01:11:14 2026 WAT
gpg: using RSA key 1FE99324758F296718B457067F4BBBBA23F0617F
gpg: issuer "sysadmin@zodl.com"
gpg: Good signature from "Zcash Open Development Lab (ZODL) (Dallas, Texas) <sysadmin@zodl.com>" [unknown]
Primary key fingerprint: 0338 34DD 49DE CF9D BB99 34BC 6C93 CA8E 58E2 6AB1
Subkey fingerprint: 1FE9 9324 758F 2967 18B4 5706 7F4B BBBA 23F0 617F
Δύο αποτελέσματα Good signature σε ένα έγγραφο, από το παλιό κλειδί και το νέο κλειδί. Αν εμπιστευόσουν το κλειδί ECC για παλαιότερες εκδόσεις, αυτή η εμπιστοσύνη πλέον μεταφέρεται στο κλειδί ZODL χωρίς να χρειάζεται να εμπιστευτείς το zodl.com, το apt.z.cash ή μια ανάρτηση σε forum. Αυτή είναι η ιδιότητα που πρέπει να αναζητάς όποτε ένα έργο αλλάζει κλειδιά — και η απουσία της αξίζει να διερευνηθεί.
Από πού να πάρεις ένα κλειδί — και από πού όχι
Από το καλύτερο στο χειρότερο:
- Μια δήλωση υπογεγραμμένη από το προηγούμενο κλειδί, όπως παραπάνω. Η ισχυρότερη επιλογή μετά από αλλαγή.
- Μια πηγή ανεξάρτητη από τη λήψη. Το binary προήλθε από το GitHub· το κλειδί από το
apt.z.cash. Ένας επιτιθέμενος χρειάζεται και τα δύο.
- Έναν keyserver, με διασταύρωση έναντι δημοσιευμένου fingerprint. Οποιοσδήποτε μπορεί να ανεβάσει σε έναν keyserver ένα κλειδί που ισχυρίζεται οποιαδήποτε ταυτότητα. Η σύγκριση fingerprint είναι που το καθιστά ασφαλές — όχι ο keyserver.
- Την ίδια σελίδα με το binary. Σχεδόν καμία διασφάλιση. Όποιος μπορεί να αντικαταστήσει το ένα, μπορεί να αντικαταστήσει και το άλλο.
Να συγκρίνεις πάντα το πλήρες fingerprint με το πρωτεύον κλειδί. Τα σύντομα IDs κλειδιών συγκρούονται εύκολα και έχουν χρησιμοποιηθεί σε πραγματικές επιθέσεις.
Μέρος 3 — Μια επαλήθευση που αποτυγχάνει
Η επαλήθευση είναι χρήσιμη μόνο αν γνωρίζεις πώς μοιάζει η αποτυχία. Ακολουθεί μια πραγματική περίπτωση, που δημιουργήθηκε προσθέτοντας ένα μόνο null byte σε ένα έγκυρο archive:
Code-highlight
cp zebrad-6.3.0-x86_64-unknown-linux-gnu.tar.gz tampered.tar.gz
sha256sum tampered.tar.gz > tampered.sha256
printf '\x00' >> tampered.tar.gz
sha256sum -c tampered.sha256
Πραγματικό αποτέλεσμα:
Code-highlight
tampered.tar.gz: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match
Exit code: 1.
Βάλε τα δύο digests δίπλα δίπλα:
Code-highlight
sha256sum zebrad-6.3.0-x86_64-unknown-linux-gnu.tar.gz tampered.tar.gz
Code-highlight
86326f5324f4e59cc2008c15f94407cc8d5feacf75d64942164bb5f08eca8c5e zebrad-6.3.0-x86_64-unknown-linux-gnu.tar.gz
8d4e2e22adcb014e006fafc71a974f987ba11297587f593cf89eb9bb1feff0b5 tampered.tar.gz
Ένα byte προστέθηκε σε αρχείο 66.992.676 byte. Τα δύο hashes δεν μοιράζονται τίποτα — ούτε πρόθεμα ούτε μοτίβο. Δεν υπάρχει μερική αντιστοίχιση και δεν υπάρχει «αρκετά κοντά»: ένα checksum είτε ταιριάζει ακριβώς είτε το αρχείο δεν είναι το αρχείο που ήθελες.
Τι να κάνεις όταν συμβεί αυτό
- Μην εκτελέσεις το binary. Μην το αποσυμπιέσεις, μην το
chmod +x.
- Δοκίμασε ξανά από την επίσημη σελίδα εκδόσεων. Οι περισσότερες αποτυχίες είναι ελλιπείς λήψεις.
- Αν αποτύχει δεύτερη φορά, άλλαξε διαδρομή δικτύου. Διαφορετική σύνδεση ή VPN. Μια αποτυχία που σε ακολουθεί σε διαφορετικά δίκτυα είναι διαφορετική από μία που δεν σε ακολουθεί.
- Επιβεβαίωσε ότι έχεις το σωστό αρχείο checksum για τη σωστή έκδοση. Η σύγκριση των sums v6.3.0 με v6.2.3 θα αποτύχει σωστά.
- Αν εξακολουθεί να αποτυγχάνει, ανέφερέ το. Άνοιξε issue στο αποθετήριο του έργου ή χρησιμοποίησε την επαφή ασφάλειας στο
SECURITY.md για οτιδήποτε υποπτεύεσαι ότι είναι σκόπιμο. Δες τη σελίδα Ασφάλεια οικοσυστήματος Zcash για κανάλια γνωστοποίησης.
- Κράτησε το artifact. Ένα παραποιημένο binary είναι αποδεικτικό στοιχείο. Μην το διαγράψεις πριν το αναφέρεις.
Μια αποτυχία υπογραφής είναι σοβαρότερη από μια αποτυχία checksum. Μια ασυμφωνία checksum είναι συνήθως αλλοίωση· ένα έγκυρο αρχείο με κακή υπογραφή δεν είναι κάτι που συμβαίνει κατά λάθος.
Μέρος 4 — Πίνακας αναφοράς
| Έργο | Εκδόσεις δημοσιεύονται στο | Μέθοδος | Από πού προέρχεται το κλειδί |
|---|
| Zebra | github.com/ZcashFoundation/zebra/releases | SHA256SUMS + Sigstore bundle | Κανένα κλειδί — ταυτότητα CI μέσω OIDC του GitHub |
| Zallet | github.com/zcash/zallet/releases | Detached GPG .asc, SLSA provenance, SBOM | apt.z.cash/zodl.asc — πρωτεύον 0338 34DD…58E2 6AB1, subkey υπογραφής 1FE9 9324…23F0 617F |
| zcashd | αποσύρθηκε | — | Σταμάτησε στο μπλοκ 3.417.100 στις 2026-07-18. Μην το εγκαταστήσεις. |
| Zodl (πρώην Zashi) | App Store / Google Play· zodl-inc στο GitHub | Store signing; standalone Android binaries GPG-signed | Κλειδί ZODL ανά δήλωση μετάβασης |
Σημείωση ονομασίας: Το Zashi μετονομάστηκε σε Zodl το 2026 — πρώτα στο App Store και έπειτα στο Google Play. Παλαιότεροι οδηγοί που αναφέρονται στο «Zashi» περιγράφουν την ίδια σειρά πορτοφολιών.
Μέρος 5 — Πορτοφόλια για κινητά και hardware wallets
Η επαλήθευση λειτουργεί διαφορετικά μόλις αφήσεις τις άμεσες λήψεις.
App stores. Δεν μπορείς να ελέγξεις μόνος σου μια υπογραφή. Το store υπογράφει το πακέτο και εμπιστεύεσαι τον έλεγχο του store και την ακεραιότητα του λογαριασμού προγραμματιστή. Αυτό που μπορείς να επαληθεύσεις είναι ότι έχεις τη σωστή εφαρμογή: επιβεβαίωσε το όνομα εκδότη και το αναγνωριστικό πακέτου έναντι του επίσημου ιστότοπου του έργου, όχι έναντι αποτελεσμάτων αναζήτησης. Οι εφαρμογές πλαστοπροσωπίας είναι συνηθισμένες και μια καταχώριση store δεν αποτελεί απόδειξη αυθεντικότητας.
Αυτόνομα APK του Android. Αυτά μπορούν να επαληθευτούν. Το ZODL δημοσιεύει αυτόνομα binaries Android με υπογραφή GPG μέσω των εκδόσεων GitHub, επομένως εφαρμόζεται η ροή εργασίας του Μέρους 2. Προτίμησε αυτή τη διαδρομή αν θέλεις μια ελέγξιμη αλυσίδα.
Hardware wallets. Η συσκευή βεβαιώνει το δικό της firmware, επομένως η άγκυρα εμπιστοσύνης είναι το hardware, όχι ένα αρχείο στο μηχάνημά σου. Δες το Keystone Zashi για τη ροή επαλήθευσης συσκευής. Αγόρασε απευθείας από τον κατασκευαστή — η παραποίηση στην αλυσίδα εφοδιασμού συμβαίνει μεταξύ εργοστασίου και αγοραστή.
Περαιτέρω ανάγνωση
Οι εντολές σε αυτή τη σελίδα εκτελέστηκαν με το Zebra v6.3.0 και το Zallet v0.1.0-beta.2 στις 2026-08-18. Τα εργαλεία εκδόσεων αλλάζουν: αν το αποτέλεσμα διαφέρει από αυτό που εμφανίζεται εδώ, εμπιστεύσου τη δική σου εκτέλεση και υπόβαλε ένα PR.
