04  ║  TRUST & DISTRIBUTION

신뢰와 배포

소스를 공개하는 것만으로는 부족해요. 받은 설치 파일이 그 소스에서 나왔는지도 볼 수 있어야 하거든요. 이 페이지는 그걸 어떻게 확인하는지 적었어요.

설치 파일은 GitHub Release에만 있어요

제3 미러나 디스코드 첨부는 쓰지 않아요. 릴리스 워크플로가 태그에서 설치 파일을 만들고 SHA256SUMS를 같이 올려요. 해시는 워크플로가 계산하니까, 릴리스 페이지의 해시와 받은 파일이 다르면 그 파일은 그 릴리스가 아니에요.

이 파일이 이 커밋에서 나왔는지는 두 가지로 봐요. 태그 빌드라서 커밋이 기록에 남고, GitHub Actions 빌드 로그가 공개돼 있어서 같은 커밋으로 다시 만들어 볼 수 있어요. 소스가 GPL-3.0인 덕분에 그 확인이 가능해요.

설치 파일에 넣는 것과, 나중에 받는 것

우리가 만들었거나 골라 넣은 것(모드 jar, 리소스, 폰트, 뉴스 글)은 설치 파일 하나에 들어 있어요. 런처가 설치 후에 따로 받는 것은 아래 세 가지예요.

  1. Minecraft 본체와 에셋 — Mojang CDN에서 받고, Mojang이 공개한 SHA1으로 확인해요. 원본을 우리가 실을 수 없어서 이렇게 받아요.
  2. Fabric Loader / API, Sodium, Lithium — 각자 공식 배포처에서 받아요. 우리가 고쳐서 다시 올리지 않아요.
  3. 뉴스 JSON — 정적 텍스트 파일이에요.

목록은 저장소의 THIRD-PARTY-NOTICES.md에 있고, 릴리스에도 같이 실려요.

자동 업데이트는 서명이 맞는 manifest만 받아요

자동 업데이트는 Tauri v2 updater를 써요. 업데이트 파일은 릴리스 워크플로에서 키로 서명하고, 클라는 서명이 맞는 manifest만 받아요. 서명 키는 GitHub Actions 시크릿에만 있어서, 로컬에서 만든 설치 파일에는 자동 업데이트가 없어요. 업데이트도 GitHub Release 한곳으로 모여요.

왜 치트가 아니냐면요

커스텀 클라이언트를 의심하는 건 당연해요. 텔레포트 같은 요청은 서버가 권한, 쿨다운, 월드를 확인하고, 클라가 보내는 값은 화면에 쓰는 데만 써요. 그 흐름은 브리지 프로토콜 페이지에 더 자세히 적어 두었어요.