Zycord문서다운로드 검증

다운로드 검증

재현 가능한 빌드는 이것은 이 소스에서 나왔고, 누구나 확인할 수 있다고 단언합니다 — 익명으로 공개되는 프로젝트가 코드 서명 인증서 대신 제공할 수 있는 보증이 바로 그것입니다. 그 보증을 받아 내는 방법은 다음과 같습니다.

세 가지 검사가 있으며, 각각 다른 질문에 답합니다. 이 순서대로 실행하세요. 각 검사는 그 앞의 검사 없이는 가치가 줄어듭니다.

검사	무엇을 증명하는가	무엇을 증명하지 못하는가
체크섬	파일이 전송 중에 변조되지 않았다는 것.	누가 만들었는지, 그 안에 무엇이 들어 있는지에 관한 어떤 것도.
서명	체크섬 목록이 프로젝트 키 보유자에게서 왔다는 것.	그 키가 여러분이 신뢰할 이유가 있는 누군가의 것이라는 점.
재빌드	바이너리가 이 소스만을 담고 있고 다른 것은 담고 있지 않다는 것.	소스가 정직하다는 점 — 직접 읽거나, 리뷰를 읽으세요.

체크섬#

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은 선택 사항도 아니고, 관대함도 아닙니다

릴리스는 이제 -randomx 아카이브만 배포하므로, SHA256SUMS.randomx가 여러분이 내려받은 것을 포괄하는 목록입니다. SHA256SUMS.deb와 SHA256SUMS.desktop은 각각 Debian 패키지와 데스크톱 지갑을 포괄합니다. 각 목록은 여러 파일을 포괄하는데 여러분은 그중 하나만 내려받았습니다. 이 플래그가 없으면 갖고 있지 않은 다섯 개가 FAILED open or read로 보고되고, 아무 문제 없는 다운로드에 대해서도 명령이 0이 아닌 코드로 종료됩니다. 그것도 불일치가 곧 변조된 바이너리를 뜻한다고 알려 주는 바로 그 페이지에서 말입니다. 정상적인 결과가 실패인 검사는 사람들이 무시하는 법을 배우게 되는 검사입니다.

서명#

아직 공개된 서명이 없으며, 이 절은 서명이 생겼을 때의 절차를 설명합니다

릴리스는 현재 공개 키인 zycord-release-key.asc를 배포하지만 — — 업데이터의 매니페스트 말고는 그 키로 서명된 것이 아무것도 없습니다. 체크섬 파일 중 어느 것에도 분리 서명이 붙어 있지 않고, 어느 것도 clearsign되어 있지 않습니다. 따라서 아래의 gpg --verify는 오늘 파일이 없다는 이유로 실패하며, 이는 여러분의 실수가 아니라 릴리스의 공백입니다. 그 공백이 메워지기 전까지 신뢰에 관한 논증을 실제로 떠받치는 검사는 재빌드입니다. 재빌드에는 서명이 전혀 필요하지 않습니다. 바이트를 직접 만들어 내어 비교하기 때문입니다.

체크섬 서명이 공개될 때 그 서명은 프로젝트 키로 만들어집니다. 전체 지문은 다음과 같습니다.

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

이 지문은 백서 헤더에, 보존된 등록본에, 그리고 제네시스 블록 공지에 공개되어 있습니다. 이 키는 조용히 교체되지 않습니다. 옛 키의 서명된 진술 없이 바뀌는 키는 침해된 키와 구별할 수 없으며, 침해된 것으로 다루어야 합니다.

기준점은 지문이지 키 파일이 아닙니다

키는 편한 곳 어디에서든 가져오고, 가져온 것을 위의 줄과 대조해 확인하세요. 지문이 그 값인 키 파일은 어느 호스트가 건네주었든 프로젝트 키이고, 지문이 다른 값인 키 파일은 호스트가 아무리 믿음직해 보였더라도 아무 가치가 없습니다.

세 곳이 이 지문을 담고 있습니다. 어느 것을 써도 됩니다.

# 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

그런 다음, 의존하기 전에 무엇이 키링에 들어왔는지 확인하세요.

gpg --fingerprint E72439CEDD8511F9D607550B87FD60D5EB4A0B29

이 키에는 keys.openpgp.org를 사용하지 마세요

이 서버는 여러 GnuPG 빌드에서 기본 키서버이며, 벗겨 낸 사본을 제공합니다. 사용자 ID도 자체 서명도 없는 맨 공개 키 패킷만 말입니다. GnuPG는 그런 사본을 거부하고 — gpg: key 87FD60D5EB4A0B29: new key but contains no user ID - skipped — 키는 키링에 들어가지 않으므로, 아래의 검증은 잘못된 서명처럼 보이지만 실은 키가 없는 것인 상태로 실패합니다. 그 서버는 자기를 통해 주소가 확인될 때까지 정책적으로 사용자 ID를 벗겨 내는데, 가명 프로젝트로서는 할 수 없는 일입니다.

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

오늘 이 명령은 No such file or directory를 보고합니다. 아직 어떤 릴리스도 그 파일을 공개하지 않았기 때문입니다. 이 절 첫머리의 안내를 보세요.

gpg는 이 키가 신뢰된 서명으로 인증되지 않았다는 말을 덧붙일 것입니다. 이는 예상된 것이며 실패가 아닙니다. 여러분이 이 키를 개인적으로 보증한다고 키링에 알린 적이 없다는 뜻이고, 지문이 존재하는 이유가 바로 그 문제를 매듭짓기 위해서입니다. 중요한 것은 서명이 검증된다는 것, 그리고 검증에 쓰인 키가 위에 인쇄된 지문의 키라는 것입니다.

백서도 서명되어 있습니다#

이 사이트에서 제공되는 PDF에는 같은 키로 만들어진 분리 서명이 나란히 놓여 있습니다.

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

재빌드 — 실제로 인증서를 대신하는 검사#

해시는 파일이 전송 중에 변조되지 않았음을 알려 줍니다. 게시자가 그 안에 무엇을 넣었는지에 대해서는 아무 말도 하지 않습니다. 다음 방법은 그것을 말해 줍니다.

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

릴리스의 SHA256SUMS.binaries와 비교하세요. 정확히 일치해야 합니다. 일치한다면, 여러분이 내려받은 바이너리는 이 소스만을 담고 있고 다른 것은 담고 있지 않습니다 — 어떤 인증서도 무엇에 대해서든 해 본 적 없는 주장입니다.

Go 툴체인도 여러분이 재현하고 있는 것의 일부입니다#

go1.26.2입니다. 같은 소스를 서로 다른 두 Go 릴리스로 컴파일하면 서로 다른 바이너리 둘이 나옵니다. 이는 미묘한 문제가 아니라 측정 가능한 사실입니다 — 이 저장소 자신의 릴리스 워크플로가 한때 하나의 커밋과 하나의 플래그 집합에 대해 Go 버전마다 하나씩 서로 다른 SHA-256 값 세 개를 기록한 적이 있습니다. 그래서 make build는 GOTOOLCHAIN=go1.26.2를 고정하며, 그 툴체인을 쓸 수 없으면 이 페이지 전체가 탐지하려는 바로 그 변조처럼 보이는 불일치를 만들어 내는 대신 설명과 함께 멈춥니다.

가질 만한 가치가 있는 두 가지 결과가 따라옵니다.

위에 적힌 버전을 신뢰할 필요는 없습니다. 릴리스된 바이너리가 그것을 스스로 진술합니다. go version -m zcd는 그것을 빌드한 툴체인을 모듈 및 빌드 플래그와 함께 출력합니다. 그 줄과 Makefile의 고정 값이 어긋난다면, 그 바이너리는 이 페이지가 말하는 방식으로 빌드된 것이 아닙니다.
오래된 태그를 체크아웃하면 그 소스와 함께 그 시점의 고정 값도 체크아웃되므로, 프로젝트가 더 새로운 Go로 옮겨 간 뒤에도 옛 릴리스의 재빌드는 계속 동작합니다.

여기서는 줄바꿈 문자도 소스의 일부입니다#

wallet/webui는 //go:embed로 지갑 프런트엔드를 내장하므로, 그 파일들의 줄바꿈 문자는 바이너리 안의 바이트가 됩니다. CRLF로 변환된 체크아웃은 같은 커밋에서 다른 zcd를 빌드합니다 — 원인은 아무 잘못이 없는데 겉보기는 무시무시한 불일치입니다. * text=auto eol=lf를 담은 .gitattributes는 모든 플랫폼과 모든 git 설정에서 작업 트리에 LF를 주므로, 새로 만든 클론은 어디서나 같은 답을 냅니다.

이것이 다루지 못하는 두 경우가 있습니다. 그 파일보다 오래된 태그를 재빌드하는 경우(체크아웃 전에 core.autocrlf=input을 설정하세요), 그리고 core.autocrlf=true로 만들어진 기존 클론인데, 이쪽은 pull한다고 해서 낫지 않습니다.

-randomx 아카이브는 구조상 재현 가능하지 않습니다

RandomX는 C++이므로 cgo 빌드는 시스템 C 툴체인을 결과물에 담고 가며, 아무도 그것을 바이트 단위로 다시 만들 수 없습니다. 그 아카이브들은 SHA256SUMS.randomx로 체크섬이 매겨지고, SHA256SUMS.binaries에는 의도적으로 빠져 있습니다. 이 목록은 여러분이 소스에서 만든 빌드가 어떤 해시가 되어야 하는지를 나열합니다. 네트워크에 참여하는 계층과 증명되는 계층이 겹치지 않는 유일한 자리가 여기입니다 — 설치 아래의 두 계층 표를 보세요. 이를 명시하는 것이 요점입니다. 그것은 여러분을 대신해 내려진 가정이 아니라 여러분의 결정입니다.

프로토콜에 대조해 구현을 확인하기#

바이너리의 출처를 확인하는 것과 별개로, 그것이 프로토콜을 구현하고 있는지도 확인할 수 있습니다. 골든 벡터가 곧 프로토콜입니다. 이를 통과하는 독립 구현은 포크가 아니라 피어입니다.

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는 가장 중요한 명령입니다. 출시 공지는 몇 주 전에 미리 코드 태그, 파라미터 해시, 제네시스 블록 id에 구속되는데 — 이 명령이 그 셋 모두를 소스로부터, 어떤 컴퓨터에서든, 밀리초 단위로 다시 만들어 냅니다. 공개 testnet의 값들은 testnet 페이지에 있습니다. 다른 값을 출력하는 빌드는 다른 체인 위의 빌드이며, 연결되지 않습니다.

독립적인 증명#

한 사람이 태그를 다시 빌드하면 그 태그가 재현 가능하다는 것이 증명됩니다. 여러 낯선 사람들이 그것을 다시 빌드하고 결과에 서명하면 그보다 훨씬 많은 것이 증명되며, 진지한 프로젝트들이 바로 이 이유로 수렴한 방식이 그것입니다. 태그를 다시 빌드한 다음, 얻은 다이제스트와 빌드한 태그를 공지 스레드에 올려 주세요 — 일치하지 않는 경우까지 포함해서입니다. 오히려 그 경우가 가장 들을 가치가 있습니다.