Перевірка релізів Zcash
Коротко
- Завантажити бінарний файл Zcash — це не те саме, що отримати саме той файл, який опублікував проєкт. Перевірка дозволяє побачити різницю.
- Контрольна сума доводить, що файл надійшов без пошкоджень. Підпис доводить, хто його створив. Потрібні обидва, а сама по собі контрольна сума доводить дуже мало.
- Zebra публікує файл
SHA256SUMS разом із пакетом Sigstore, який прив’язує реліз до конкретного workflow GitHub Actions, тегу й коміту — керування ключами не потрібне.
- Zallet публікує відокремлені GPG-підписи (
.asc) разом із SLSA provenance та SBOM.
- У 2026 році ключ підпису Zcash було змінено з Electric Coin Company на Zcash Open Development Lab (ZODL). Якщо ви перевіряли старіші релізи, вам потрібен новий ключ — і заява про передачу підписана обома ключами, тож ви можете перевірити саму ротацію.
gpg повідомляє про підключ, яким підписано файл, а не про основний ключ, згаданий в оголошеннях. Відбиток, який здається неправильним, зазвичай є підключем, а не ознакою атаки.- Якщо перевірка не пройшла, не запускайте бінарний файл.
Перевірено на Zebra v6.3.0 і Zallet v0.1.0-beta.2 станом на 2026-08-18.
Чому це особливо важливо для Zcash
Підроблений бінарний файл гаманця може викрасти spending key або viewing key. На відміну від скомпрометованого пароля, така втрата є незворотною: немає ні відкату, ні чарджбеку, ні служби підтримки. Shielded-транзакції захищають те, що відбувається у блокчейні — але зовсім не захищають, якщо програмне забезпечення, яке ви запускаєте, було підмінене ще до того, як потрапило до вас.
Це один із небагатьох шляхів атаки, де гарантії приватності самого протоколу просто не мають значення. Перевірка — це той рівень захисту, який це покриває.
Модель загроз — що перевірка виявляє, а що ні
Виявляє:
- Підроблене дзеркало або змінений файл, отриманий звідкись, окрім сторінки релізу проєкту.
- Підміну файлу під час завантаження через атаку man-in-the-middle.
- Скомпрометований CDN або захоплений хост розповсюдження.
- Випадкове пошкодження під час передачі.
Не виявляє:
- Мейнтейнера, який підписує шкідливий код. Підпис перевіриться коректно; він доводить походження, а не намір.
- Скомпрометований сервер збірки, що створює підписаний, але шкідливий артефакт. Саме для звуження цієї загрози існують відтворювані збірки та provenance attestation.
- Ключ, який ви отримали з того самого скомпрометованого джерела, що й бінарний файл. Якщо атакувальник контролює і файл, і ключ, з яким ви його звіряєте, перевірка нічого вам не скаже.
Саме цей останній пункт більшість інструкцій пропускає. Звідки ви берете ключ, настільки ж важливо, як і сам запуск команди.
Частина 1 — Zebra: контрольні суми та Sigstore
Zebra публікує для кожного релізу такі файли:
| Файл | Призначення |
|---|
zebrad-<version>-<arch>.tar.gz | архів із бінарним файлом |
zebrad-<version>-<arch>.tar.gz.sha256 | контрольна сума для окремого файлу |
SHA256SUMS | контрольні суми для всіх архітектур |
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 — Перевірте контрольну суму
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
Самого лише цього кроку недостатньо. Ви завантажили контрольну суму з того самого місця, що й бінарний файл. Кожен, хто міг підмінити одне, міг підмінити й інше. Контрольна сума доводить цілісність; наступний крок доводить походження.
Крок 2b — Та сама перевірка у 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
Значення ідентичні. Для шістнадцяткових чисел регістр не має значення, і це найпоширеніша хибна тривога у Windows.
Ще дві пастки, характерні саме для Windows:
- Немає коду завершення, який можна перевірити. У Linux
sha256sum -c повертає 1 у разі помилки, і скрипт може на це зреагувати. Get-FileHash лише виводить хеш — порівняння ви робите самі, і саме ви можете помилитися, переглянувши результат надто побіжно.
- Читати 64 шістнадцяткові символи очима ненадійно. Нехай це зробить оболонка:
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 та записаними у публічний журнал прозорості. Ніхто не зберігає ключ релізу, який можна викрасти.
Найпростіший шлях — через 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
Два прапорці --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, але старі релізи не шукають його там. Це обмеження клієнта, а не зламаний реліз. Якщо ви з цим зіткнулися, оновіть 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 і тег. 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 |
Кожне з цих значень можна перевірити. Хеш коміту має збігатися з тегом у репозиторії; запуск 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 — Запис у журналі прозорості
Пакет містить запис Rekor, який доводить, що підпис було опубліковано в публічному, лише-дописуваному журналі:
| Поле | Значення |
|---|
| Rekor log index | 2412071838 |
| Entry type | hashedrekord v0.0.1 |
| Integrated at | 2026-08-10 19:43:09 UTC |
Саме це робить можливим виявлення тихого зловживання ключем. Підпис, який ніколи не з’являвся в журналі або з’явився в неправдоподібний час, є сигналом, на який варто реагувати. Порівняйте час інтеграції з часом оголошення релізу.
Примітка щодо шляху через OpenSSL: він перевіряє підпис відносно публічного ключа сертифіката, але сам по собі не валідує ланцюжок сертифіката до кореня Sigstore і не перевіряє inclusion proof запису в журналі. cosign verify-blob робить усі три перевірки. Використовуйте OpenSSL, щоб зрозуміти механізм; використовуйте cosign як фактичну перевірку.
Частина 2 — GPG-підписи Zallet
Zallet публікує інший набір файлів:
| Файл | Призначення |
|---|
zallet-<version>-<platform>.tar.gz | архів із бінарним файлом |
.tar.gz.asc | відокремлений GPG-підпис |
.tar.gz.intoto.jsonl | SLSA provenance attestation |
.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
Це не помилка. Це означає, що підпис існує, і точно вказує, який саме ключ вам потрібен, ще до того, як ви почнете його шукати. Запишіть відбиток і issuer, а тоді отримайте ключ із джерела, незалежного від завантаження.
gpg виводить часові мітки у вашому локальному часовому поясі. У прикладі вище показано 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 — саме це вам і потрібно було побачити. Дві речі в цьому виводі часто бентежать людей, і обидві є нормальними.
Чому відбиток не збігається з оголошенням
У заяві про перехід ключа ZODL вказано відбиток 0338 34DD 49DE CF9D BB99 34BC 6C93 CA8E 58E2 6AB1. Але gpg --verify показав 1FE9 9324 … 23F0 617F. Це виглядає як невідповідність, але не є нею.
gpg повідомляє про підключ, яким було зроблено підпис. В оголошенні вказано основний ключ. Підтвердіть зв’язок самостійно:
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 — це підключ підпису; рядок pub — основний ключ. Одна ідентичність, один набір ключів. Саме тому у виводі перевірки показано обидва відбитки — порівнюйте основний з будь-яким опублікованим оголошенням, а рядок із підключем сприймайте як інформацію про те, яка частина ключа виконала підпис.
Такий поділ ключів є навмисним: підключ підпису можна замінити або відкликати, не відмовляючись від основної ідентичності та накопиченої до неї довіри.
Що означає попередження [unknown]
Code-highlight
gpg: WARNING: The key's User ID is not certified with a trusted signature!
Це не проблема з підписом. Підпис криптографічно коректний — саме це означає Good signature. Попередження каже про інше: ви не повідомили своєму локальному GnuPG, що вірите, ніби цей ключ справді належить тому, за кого себе видає.
GnuPG розділяє два питання:
- Чи цей ключ підписав цей файл? — на це відповідає
Good signature. Це криптографія, без людських суджень.
- Чи цей ключ належить ZODL? — на це криптографія не відповідає взагалі. Ви встановлюєте це, звіряючи відбиток із незалежним джерелом.
Ви бачитимете це попередження майже під час кожної перевірки, якщо спеціально не підпишете ключ локально. Не сприймайте його як помилку. Але сприймайте відсутність Good signature як помилку.
Крок 3 — Перевірте сам перехід ключа
Підписання релізів Zcash перейшло від Electric Coin Company до Zcash Open Development Lab у 2026 році, після того як ZODL була створена в січні 2026 року колишньою командою інженерів і продукту ECC.
| Старий ключ | Новий ключ |
|---|
| Відбиток | 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-бітний, створений 2023-06-19 | RSA 4096-бітний, створений 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 або допису на форумі. Саме цю властивість слід шукати щоразу, коли проєкт змінює ключі — і її відсутність варта запитань.
Де брати ключ — і де не варто
Від найкращого варіанта до найгіршого:
- Заява, підписана попереднім ключем, як вище. Найсильніший варіант після ротації.
- Джерело, незалежне від завантаження. Бінарний файл прийшов із GitHub; ключ — з
apt.z.cash. Атакувальнику потрібен контроль над обома.
- Сервер ключів, звірений з опублікованим відбитком. Будь-хто може завантажити на більшість серверів ключів ключ із будь-якою заявленою ідентичністю. Безпечним це робить саме порівняння відбитка, а не сервер ключів.
- Та сама сторінка, що й бінарний файл. Майже жодних гарантій. Той, хто може підмінити одне, може підмінити й інше.
Завжди звіряйте повний відбиток з основним ключем. Короткі ідентифікатори ключів легко колідують і вже використовувалися в реальних атаках.
Частина 3 — Перевірка, яка не проходить
Перевірка корисна лише тоді, коли ви знаєте, як виглядає збій. Ось реальний приклад, отриманий додаванням одного нульового байта до правильного архіву:
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
Код завершення: 1.
Покладіть два digest поруч:
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
Один байт, доданий до файлу розміром 66,992,676 байтів. Ці два хеші не мають нічого спільного — ні спільного префікса, ні патерну. Не буває часткового збігу і не буває "майже збігається": контрольна сума або збігається точно, або файл не є тим файлом, який вам був потрібен.
Що робити, коли це сталося
- Не запускайте бінарний файл. Не розпаковуйте його і не виконуйте
chmod +x.
- Спробуйте ще раз з офіційної сторінки релізу. Більшість збоїв — це обірвані завантаження.
- Якщо збій повторився вдруге, змініть мережевий шлях. Інше з’єднання або VPN. Збій, який повторюється в різних мережах, відрізняється від збою, який не повторюється.
- Переконайтеся, що у вас правильний файл контрольних сум для правильної версії. Порівняння сум для v6.3.0 із файлом v6.2.3 правильно завершиться помилкою.
- Якщо все одно не проходить, повідомте про це. Відкрийте issue у репозиторії проєкту або скористайтеся контактами безпеки з
SECURITY.md, якщо підозрюєте навмисні дії. Канали розкриття дивіться на сторінці Безпека екосистеми Zcash.
- Збережіть артефакт. Підроблений бінарний файл — це доказ. Не видаляйте його до повідомлення.
Помилка підпису серйозніша за помилку контрольної суми. Невідповідність контрольної суми зазвичай означає пошкодження; правильний файл із неправильним підписом не трапляється випадково.
Частина 4 — Довідкова таблиця
| Проєкт | Де публікуються релізи | Метод | Звідки береться ключ |
|---|
| Zebra | github.com/ZcashFoundation/zebra/releases | SHA256SUMS + Sigstore bundle | Ключа немає — ідентичність CI через GitHub OIDC |
| Zallet | github.com/zcash/zallet/releases | Detached GPG .asc, SLSA provenance, SBOM | apt.z.cash/zodl.asc — основний 0338 34DD…58E2 6AB1, підключ підпису 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 згідно із заявою про перехід |
Примітка щодо назви: у 2026 році Zashi було перейменовано на Zodl — спочатку в App Store, потім у Google Play. Старіші інструкції, де згадується "Zashi", описують ту саму лінійку гаманця.
Частина 5 — Мобільні та апаратні гаманці
Після переходу від прямих завантажень перевірка працює інакше.
Магазини застосунків. Ви не можете самостійно перевірити підпис. Пакет підписує магазин, і ви довіряєте перевірці магазину та цілісності облікового запису розробника. Що можна перевірити — це що у вас саме правильний застосунок: звірте назву видавця та ідентифікатор пакета з офіційним сайтом проєкту, а не з результатами пошуку. Застосунки-імітації трапляються часто, а картка в магазині не є доказом справжності.
Окремі Android APK. Їх можна перевіряти. ZODL публікує окремі Android-бінарники, підписані GPG, через GitHub Releases, тож тут застосовується процес із Частини 2. Якщо ви хочете ланцюжок, який можна перевірити, надавайте перевагу саме цьому шляху.
Апаратні гаманці. Пристрій засвідчує власну прошивку, тож коренем довіри тут є апаратне забезпечення, а не файл на вашому комп’ютері. Дивіться Keystone Zashi для процесу перевірки пристрою. Купуйте безпосередньо у виробника — втручання в ланцюг постачання трапляється між фабрикою і покупцем.
Додаткове читання
Команди на цій сторінці були виконані для Zebra v6.3.0 і Zallet v0.1.0-beta.2 станом на 2026-08-18. Інструменти релізів змінюються: якщо вивід відрізняється від показаного тут, довіряйте власному запуску і, будь ласка, відкрийте PR.
