Debian Bookworm 라이브 이미지, 100% 재현 가능해짐

 (lwn.net)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Debian 12.10 “bookworm”의 라이브 이미지가 같은 입력으로 동일한 결과를 만들 수 있는 100% 재현 가능 상태에 도달함
  • Debian 개발자 Roland Clobus가 Reproducible Builds 메일링 리스트에 짧은 노트로 이 사실을 공유함
  • 이번 발표는 Debian 라이브 이미지 재현성 작업이 bookworm 릴리스 계열에서 확인 가능한 성과를 냈다는 점에서 중요함
  • 세부 정보는 Debian 위키의 reproducible live images 문서와 Debian Live todo 문서에서 이어서 확인할 수 있음
  • 배포 이미지 검증이나 재현 가능한 설치 환경을 다루는 실무자는 해당 위키 문서를 참고 지점으로 삼을 수 있음

Debian 12.10 라이브 이미지 재현성

  • Debian 개발자 Roland Clobus가 Reproducible Builds 메일링 리스트에 짧은 노트를 올려 Debian 12.10 “bookworm” 라이브 이미지가 100% 재현 가능해졌다고 밝힘
  • 대상은 Debian 12.10, 코드명 bookworm의 라이브 이미지임

확인할 문서

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 엄청난 노력임. 불과 몇 년 전만 해도 이런 건 허황된 꿈처럼 들렸는데, 참여한 모두, 특히 이 작업을 밀어붙인 사람들에게 축하를 보냄

    • Debian 그룹은 존경스럽고, 운영체제 설계 기준을 여러 번 좋은 방향으로 바꿔 왔음. 세금 신고 시즌쯤 커피 기금에 기부해야겠다는 생각이 듦

  • 빌드 재현성을 어떻게 달성하는지 잘 모르겠음. 파일 생성/수정 시각 같은 메타데이터는 어떻게 처리하는지 궁금함
    위조하는 건지, 아니면 내용이 같고 메타데이터만 다른 두 파일은 해시할 때 같은 체크섬을 가져야 한다는 식으로 중요하지 않게 보는 건지 모르겠음

    • Debian은 이 문제를 일부 해결하려고 strip-nondeterminism이라는 도구를 씀: https://salsa.debian.org/reproducible-builds/strip-nondeterm...
      Debian 사이트에는 재현성 작업에 관한 정보가 많고, 2024년 DebConf 관련 기사도 볼 만함: https://lwn.net/Articles/985739/
    • 타임스탬프는 가장 쉬운 부분임. 선택한 기준 시각에 맞춰 전부 설정하면 됨
      어려운 건 불안정한 해시 순서, 정렬되지 않은 파일시스템 목록, 병렬 실행, 주소 공간 무작위화 같은 것들임
    • 대체로 맞음: https://reproducible-builds.org/docs/timestamps/
      빌드가 재현 가능하다면 언제 빌드했는지는 중요하지 않아야 함. 빌드를 소스까지 추적하고 싶다면 타임스탬프보다 훨씬 나은 방법들이 있음
    • 맞음. 모든 아카이브 항목, 날짜 관련 소스 코드 매크로, 그 밖의 모든 타임스탬프를 표준화된 과거 날짜로 설정함
    • 어쩌면 바보 같은 질문일 수 있는데, 이게 왜 재현성을 바꾸는지 궁금함. Git 저장소를 복제하면 Git에 저장된 메타데이터가 그대로 오지 않나? 아니면 파일 수정 시각이 복제 시점으로 찍히나?
      실제로 확인해 본 적은 없음

  • 내가 이해한 바로는 이건 소스에서 .deb 파일을 만드는 게 아니라, .deb 파일들로부터 .iso 파일을 생성하는 것에 관한 얘기임. 소스에서 .deb를 재현 가능하게 만드는 작업은 아직 진행 중임

  • Debian의 빌드 인프라 자체도 재현 가능한가? 누군가 소스에는 넣지 않고 Debian 패키지 바이너리에 악성코드를 주입하려면 빌드 인프라, 즉 컴파일러, 링커, 그 주변 래퍼 코드를 노려야 할 것 같음
    또 다른 누군가도 이 이미지들을 컴파일해서 Debian 컴파일 서버가 침해되지 않았다는 증거를 제공하고 있는지도 궁금함

    • Debian의 재현성 결과를 볼 수 있는 페이지가 있음: https://tests.reproducible-builds.org/debian/bookworm/index_...
      이미지에 대해서도 비슷한 것이 있었던 것 같지만, 틀렸을 수도 있고 지금 링크는 없음
      안내문에 있는 링크들을 따라가면 Debian 사이트에 관련 문서가 많음. LWN도 작년에 DebConf에서 Holger Levsen이 이 주제로 한 발표를 다룬 기사를 냈음: https://lwn.net/Articles/985739/
    • 재현 가능한 빌드의 핵심은 빌드 봇이 침해되더라도 보안을 확인할 수 있게 하는 데 있음
    • 그럼 빌드가 실행되는 하드웨어는? 그것도 재현 가능한가? ;)
    • xz 같은 경우가 떠오름
      결국 신뢰의 뿌리는 어떤 바이너리 집합과 사용하는 하드웨어에 둘 수밖에 없음

  • 재현 가능한 빌드의 의미가 무엇이고, 일반 배포판과는 어떻게 다른지 궁금함

    • 재현 가능하다는 건 Alice와 Bob이 같은 소스 코드를 내려받아 컴파일하면, Alice의 바이너리와 Bob의 바이너리가 바이트 단위로 완전히 동일하다는 뜻임
      일반적으로는 Debian이 이 문제를 다루기 전까지, 시스템별 차이가 바이너리에 섞여 들어가는 모든 방식에 대해 대부분 깊게 생각하지 않았음. 예를 들면 C의 __DATE__, __TIME__ 매크로, 병렬 빌드가 다른 순서로 끝나는 경우, tar나 zip 파일을 만드는 도구가 기본적으로 운영체제에 입력 파일의 수정 시간을 물어보고 그 값을 tar 바이트에 넣는 경우, 파일시스템이 디렉터리 파일을 다른 순서로 나열하고 그 순서가 tar/zip이나 다른 곳에 보존되는 경우 등이 있음
      중요한 이유는, 재현 가능한 빌드가 있으면 누구나 Debian의 공식 바이너리가 소스 코드와 일치하는지 확인할 수 있기 때문임. 앞으로 Debian에 백도어나 악성코드를 몰래 넣으려는 공격자는 소스 코드에 넣을 방법을 찾아야 하고, 그러면 사람들이 발견하기가 더 쉬워짐
    • 오픈소스는 “실행하는 코드의 소스를 볼 수 있다”는 뜻임. 그런데 실제 실행 파일이 정말 그 코드에서 빌드됐는지는 어떻게 아나? 배포판을 믿거나, 직접 빌드해야 하는데 그건 번거로울 수 있음
      이제 빌드가 재현 가능하면 배포판만 믿을 필요가 줄어듦. 항상 정확히 같은 바이너리가 나오므로 올바른 sha256sum이 하나로 정해짐. 신뢰하는 다른 10개 주체가 같은 코드로 같은 바이너리를 빌드하고 그 sha256sum에 서명해 공개하면, 사용자는 그 10개를 확인할 수 있음. 서로 다른 10개 주체가 공모해 거짓말할 가능성은 배포판 하나만 거짓말할 가능성보다 훨씬 낮음
    • 재현 가능한 빌드는 실제로 많은 문제를 해결함. 그게 진짜 문제인지까지는 모르겠지만, 사람들은 그 문제를 풀려고 많은 돈을 씀
      전 직장에서 어떤 팀은 연방정부 고객을 위해 우리 소프트웨어가 특수한 연방정부 빌드 클러스터에서 빌드되도록 엄청 오래 작업했음. Docker Hub에서 Docker 이미지를 가져오면 안 되고, 컨테이너가 그들의 인프라에서 조립되어야 한다는 요구사항이 있었던 듯함. 반면 우리 빌드는 재현 가능했고 Bazel 외부 의존성이 없어서, 릴리스 브랜치를 git checkout하고 bazel build //oci를 실행하면 컨테이너의 sha256이 Docker Hub에 있는 것과 동일한지 검증할 수 있었음. 특수 인프라가 필요 없었고, 아키텍처와 플랫폼을 가로질러서도 동작했음. CI 머신은 linux / x86_64였지만 darwin / aarch64 노트북에서 빌드해도 매번 정확히 같은 바이트가 나왔음
      모든 것이 재현 가능한 세상에서는 보안 빌드를 위해 특수 컴퓨터가 필요 없음. 평범한 컴퓨터 여러 대에서 빌드하고 모두 같은 바이트를 생성하는지 확인하면 됨. 꽤 멋짐
      덧붙이면 정부 요구사항은 말이 안 됐음. 최종 빌드 방식은 우리 CI 시스템이 바이너리를 만들고, 그 바이너리를 특수 클러스터로 보낸 뒤, 거기서 특수 Dockerfile이 고객이 사용할 이미지로 조립하는 식이었음. 내가 보기엔 이 방식은 이미지 안에 우리가 말한 코드가 들어 있다는 보장을 전혀 주지 않지만, 체크박스는 채웠음. 앞으로 4년 동안 이런 일이 더 나아질 것 같지는 않음
    • https://en.wikipedia.org/wiki/Reproducible_builds
      https://wiki.debian.org/ReproducibleBuilds/About
    • 직접 빌드할 수 있고, 가지고 있는 소스 코드가 전부라는 걸 알 수 있다는 뜻임
      공개 다운로드물이 주장된 것과 다르지 않다는 점을 검증해 줌

  • 좋다. 이 라이브 이미지들은 Debian 기반 불변 운영체제 작업 흐름의 토대가 될 수 있음

  • 이 라이브 이미지에는 cloud-init이 준비돼 있나? 메모리에서 실행되는 cloud-init 라이브 ISO라면 “어디서나” 쓰는 불변 인프라에 딱 맞아 보임

    • 없다 해도 넣기는 사소할 것 같음. 이미지를 재현하면서 패키지를 설치하고, 필요하면 데이터소스 힌트를 좀 준비하면 됨. 어디서 사용할지에 따라 달라짐
      늘 그렇듯 세부사항이 까다로울 것임. 사용자 데이터가 유용한 일을 하면서도 불변성과 잘 어울려야 함
      본질적으로 저항하는 무언가를 억지로 다듬으려는 곡예를 하기보다는, 재현성에 기대는 편이 더 합리적일 것 같음. 원하는 대로 만들고 추가 작업은 건너뛰면 됨
      하나 더 필요하면? 좋음. 자유롭게 재현 가능함 :)

  • 이건 큰 이정표임: https://lists.reproducible-builds.org/pipermail/rb-general/2...

  • 이 주제는 초보라서 궁금함. 빌드가 어떻게 비재현적일 수 있나? 즉 빌드 과정의 어느 부분이 비결정적 출력을 낼 수 있는지 모르겠음. 사람들이 타임스탬프 같은 걸 빌드 결과물에 넣는 건가?

    • 파일 경로, 타임스탬프, 입력/출력의 불안정한 순서, 로케일, 버전 정보, 빌드 환경의 차이 등이 있음
      이 페이지에 잘 정리돼 있음
      https://reproducible-builds.org/docs/
    • 타임스탬프, 타임스탬프, 절대 경로, 예를 들어 /src에서 빌드하는 것과 /home/Cort3z/source에서 빌드하는 차이, 타임스탬프, 파일 아이노드 번호가 있음. 많은 언어에서 “디렉터리 안의 파일을 순회”할 때 기본값이 알파벳순이 아니라 아이노드 순서라 사실상 의사난수처럼 동작함. 거기에 더 많은 타임스탬프, 빌드 과정에서 난수 데이터를 쓰는 경우, 예를 들어 생성된 개인 키를 포함하거나 무언가에 서명하는 경우, 또 타임스탬프, 그리고 컴파일러 내부의 우발적 비결정성이 있음
      압도적으로 가장 흔한 비결정성 원인은 타임스탬프임. 특히 예상하지 못한 파일 형식에도 타임스탬프가 숨어 있음. 예를 들어 gzip을 실행하면 대체 왜인지 출력에 타임스탬프를 넣음. 그다음은 파일시스템의 두 큰 문제인 절대 경로와 디렉터리 순회 비결정성이고, 이후는 한두 패키지에만 영향을 주는 개별 문제들의 긴 꼬리임
답변달기