▲

Debian은 재현 가능한 패키지를 제공해야 함

 (lists.debian.org)
1P by GN⁺ 14시간전 | ★ favorite | 댓글 2개
  • Debian 릴리스 팀이 forky 주기 중간에 재현 가능한 패키지 제공을 결정함
  • 마이그레이션 소프트웨어가 reproduce.debian.net에서 재현되지 않는 새 패키지를 차단함
  • testing의 기존 패키지에 재현성 퇴행이 생겨도 마이그레이션이 차단됨
  • binNMU에도 source-full 업로드처럼 autopkgtest 실행 기능이 추가됨
  • loong64 추가와 multi-arch 재빌드로 CI 대기열이 커져 인내가 필요함

Debian 패키지 재현성 의무화

  • Debian 릴리스 팀은 forky 릴리스 주기 중간 지점에서 Debian이 재현 가능한 패키지를 제공해야 한다고 결정함
  • 이 결정은 Reproducible Builds 프로젝트의 노력에 힘입은 것임
  • 전날부터 마이그레이션 소프트웨어가 reproduce.debian.net에서 재현되지 않는 새 패키지의 마이그레이션을 차단하도록 활성화됨
  • testing에 이미 있는 기존 패키지에서 재현성 퇴행이 발생하는 경우에도 마이그레이션이 차단됨

품질 보증과 업로더 책임

  • testing binNMU의 autopkgtest 실행

    • 올해 초 마이그레이션 소프트웨어에 binNMU도 source-full 업로드와 마찬가지로 autopkgtest를 실행하는 기능이 추가됨
    • 이 기능은 대부분의 메인테이너 작업과 직접 관련이 크지 않을 수 있지만, 품질 보증을 강화하는 또 하나의 단계로 다뤄짐

  • loong64 아키텍처 추가와 CI 대기열 증가

    • 2주 전 아카이브에 새 아키텍처 loong64가 추가됨
    • Debian은 buildd에서 빌드된 바이너리만 마이그레이션하도록 허용하며, multi-arch 요구사항 때문에 모든 아키텍처에서 상당수 패키지를 다시 빌드해야 했음
    • 앞서 추가된 binNMU 기능 때문에 현재 CI 대기열이 꽤 커졌으며, 릴리스 팀은 약간의 인내를 요청함

  • 업로드 이후 후속 조치

    • 소스 패키지 업로더는 해당 패키지가 마이그레이션되도록 보장할 책임이 있음
    • 패키지가 역방향 테스트 의존성의 autopkgtest 회귀로 막혀 있고 그 의존성 업데이트가 필요하다면, 업로더가 적절한 RC 심각도의 버그를 제출해야 함

함께 보면 좋은 글 β

▲
GN⁺ 11시간전  [-]
Hacker News 의견들

  • Debian과 자유 소프트웨어 세계에 큰 성과임
    다만 이 필요성이 이해되기까지는 시간이 꽤 걸렸음. 2007년에 debian-devel에서 이게 필요하다고 말했을 때도 엄청난 시간 낭비라는 답을 들었고, 실제로 여기까지 오려면 많은 사람의 막대한 작업이 필요했지만 충분히 그럴 가치가 있었음

    • 2007년 이후 Debian에서 재현 가능한 패키지가 막을 수 있었던 버그나 공격은 없었음
      “그럴 가치가 있었다”는 말은 맞지 않다고 봄. Debian 기여 장벽만 더 높이는 일이고, 이미 Debian 기여가 어렵다고 불평하는 사람을 많이 봤음. 예전에는 “패키지들이 서로 잘 맞물리도록 온갖 검증과 견제가 필요하다”고 옹호했지만, 이건 별 이유 없이 어렵게 만들고 이득은 작은 단계로 보임

  • https://wiki.debian.org/ReproducibleBuilds에 정보가 더 있음. 일부는 오래됐지만, CI에서 빌드되는 패키지 수와 그중 재현 가능한 빌드가 얼마나 되는지 보여주는 차트도 있음
    주황색은 FTBR, 즉 “재현 가능하게 빌드 실패”를 뜻함. 차트에서 숫자를 읽는 데 익숙하진 않지만 대략 몇 퍼센트, 4~5% 정도로 추정함

    • 내게는 이렇게만 나옴:

      Forbidden

      You are not allowed to access this!
      HTML 태그까지 그대로 보임 :)
      편집: 기록에서 “I Challenge Thee” 페이지도 찾았음. 혹시 봇 방지 조치에 막힌 건가? 왜???

  • 좋은 일임. NetBSD는 2017년부터 완전히 재현 가능한 빌드를 갖췄음. https://blog.netbsd.org/tnf/entry/netbsd_fully_reproducible_...

    • 링크에도 나오듯 NetBSD는 Debian의 도움을 받아 그걸 달성했음. 제대로 이해했다면 NetBSD가 더 열심히 해서라기보다 문제가 더 쉬웠던 것임. 패키지가 더 적고 변경도 덜 됨. 아직도 CVS를 쓰니 “안정성”이라는 말로는 부족할 정도임
      참고로 Debian 패키지 대부분은 재현 가능한 빌드임. 그렇지 않은 것들, 대략 5%쯤 되는 패키지는 여기 그래프에서 주황색으로 표시됨: https://wiki.debian.org/ReproducibleBuilds
    • 자랑을 하자면 stagex는 작년에 100% 전체 소스 부트스트랩 기반의 결정적이고 격리된 빌드를 처음 달성했고, 매 릴리스마다 서로 다른 유지보수자가 각자 하드웨어에서 수행한 여러 개의 서명된 재현을 의무화한 것도 처음임
      Debian도 많이 발전했지만, Debian이 재현 가능하다고 할 때는 자기 빌드를 위해 서드파티 바이너리를 가져온다는 뜻임. 우리가 재현 가능하다고 할 때는 전체 소프트웨어 공급망 끝까지 100% 소스 코드에서 부트스트랩한다는 뜻임
      이 차이는 중요하다고 봄
      https://stagex.tools

  • 이 변화가 정말 반가움. 2021년에 SolarWinds 공격을 읽고 충격을 받은 뒤 재현 가능한 빌드에 참여하게 됐음. [1]
    OpenJDK의 재현 가능한 빌드를 작업하던 Magnus Ihse Bursie의 말이 가장 적절하다고 봄: “내게 묻는다면, 컴파일러와 빌드 도구가 언젠가부터 비결정적 출력을 만들기 시작했다는 사실 자체가 첫날부터 버그였다.” [2]
    [1] https://www.linux.com/news/preventing-supply-chain-attacks-l...
    [2] https://github.com/openjdk/jdk/pull/9152#issue-1270543997

  • 요즘 왜 이게 이슈가 되는지 궁금함. 임베디드 기기에 Yocto를 쓰는데, 재현 가능한 빌드는 거의 당연하게 구현할 수 있었음
    Debian 패키지 관리도 쉽게 켤 수 있으니 이미 다 가능한 것 아닌가 싶음

    • “요즘 왜 이게 이슈냐”는 게 무슨 뜻인지 궁금함
      재현 가능한 빌드는 산업용 컴퓨팅에서 필수적인 방법임. Debian이 이 분야의 최전선에 있다기보다, 장기 운용 및 안전 관련 용도에서 쓰이는 다른 운영체제에도 적용되는 업계 전반의 기법을 받아들이는 것에 가까움
      물론 Yocto와 Debian 개발자들의 많은 어려운 작업 덕분에 이미 손쉽게 쓰고 있는 부분도 큼
      흥미로운 건 이제 Debian 개발자들이 이걸 더 전향적인 정책으로 적용해, 선택지가 아니라 기본 규범으로 만들고 있다는 점임
    • 실제로 빌드가 비트 단위로 재현 가능한지 능동적으로 검증했는지가 궁금함

  • amd64 forky 기준
    reproduced: 97.02%
    good: 17586
    bad: 511
    fail: 30
    unknown: 0
    이 통계와 다른 아키텍처 통계, 재현 불가능한 이유는 https://reproduce.debian.net에서 볼 수 있음

  • Debian이 이걸 주도하고 상용 벤더가 아니라는 점이 늘 의외임. RHEL과 Ubuntu에 돈을 내는 큰 조직들이 검증 가능한 바이너리를 강하게 요구할 법한데

    • 경쟁사가 자기 패키지가 큰 조직이 배포하는 것과 비트 단위로 동일하다는 걸 증명할 수 있다면, 그 경쟁사는 큰 조직의 보안 보증에서 이득을 얻을 수 있음
      자유 소프트웨어에는 아주 좋지만, 독점자가 되고 싶은 쪽에는 그리 좋지 않음
    • 재현 가능한 빌드는 신뢰 필요성을 줄이기 위해 존재하지만, 상용 벤더는 신뢰를 파는 사업을 함

  • Forbidden
    You don't have permission to access this resource.
    Apache Server at lists.debian.org Port 443
    :/

답변달기
▲
GN⁺ 14시간전  [-]
Lobste.rs 의견들

  • 보안 측면에서 좋은 변화임. 전환 과정은 번거로울 수 있지만, 최종적으로 전 세계 Debian Linux 사용자에게 더 높은 신뢰성을 제공하게 됨

  • Debian 같은 프로젝트에 주는 핵심 이점이 뭔지 궁금함. 바이너리에 백도어가 없다는 증거를 모두가 가질 수 있게 하려는 건가?
    즉, 유지관리자에게 요구되는 신뢰를 줄이고 악의적인 유지관리자 위험도 낮추는 효과인지 궁금함. 회의적인 건 아니고, Debian이 왜 여기에 그렇게 많은 시간을 쓰는지 100% 이해하지 못했음. 빌드를 재현 가능하게 만드는 일은 꽤 까다롭고 손이 많이 갈 것 같음

    • 백도어뿐 아니라 일반적인 변조나 수정 여부도 확인할 수 있게 함. 이는 보안에도 도움이 되고 프로젝트 개발에도 이점이 있는데, 재현 가능하고 어느 정도 밀폐된 방식으로 빌드되는 패키지는 다른 개발자 환경에서 이상하게 깨질 가능성이 줄어듦
      핵심은 출력 패키지를 만든 소스 코드가 정말 그 특정 소스 코드이며, 숨겨진 두 번째 소스 묶음이 아니라는 증거 산출물을 제공하는 것임. the reproducible-builds org has a bit of a 'why' which puts it better than i can
      재현 가능한 빌드를 만드는 건 매우 어렵다. 예를 들어 컴파일 파이프라인 안의 타임스탬프도 차이를 만들고, 생성된 아카이브의 메타데이터도 마찬가지임. 이런 것들을 모두 제거해야 하고, 경우에 따라 패키지 자체가 아니라 CMake나 Go 컴파일러 같은 상류 프로젝트 패치가 필요함. 많은 경우 예전에는 이런 문제가 고려 대상조차 아니었기 때문에, 빌드 스택 전체에 걸쳐 작업이 들어가야 함. 다만 이 작업은 오래전부터 진행되어 와서, 하부 배관의 상당 부분은 이미 끝났거나 깊게 진행 중임
    • 이것이 Debian의 최우선순위가 되어야 한다고는 생각하지 않지만, Debian은 그런 식으로 움직이지 않음. 사람들은 자기가 하고 싶은 일을 하고, 개인의 우선순위는 프로젝트 차원에서 합리적인 우선순위와 잘 맞지 않는 경우가 많음

  • Debian이 말하는 재현 가능성은 NixOS 같은 곳에서 말하는 것과 같은 개념인가?

    • 아님. NixOS is not reproducible가 표준 참고 글임
    • 재현 가능한 빌드를 프로젝트로 추적하는 배포판들은 대체로 같은 목표를 향해 감. reproducible-builds.org는 패키징 파이프라인에서 이를 적극적으로 작업 중인 프로젝트들을 추적함
      NixOS도 재현 가능한 빌드를 작업 중이고, 기억이 맞다면 최소 ISO는 빌드와 런타임 모두 100% 재현 가능함. 하지만 흔히 NixOS에 대해 말하는 재현 가능성은 여기서 논의하는 “재현 가능한 빌드”가 아님. 이 스레드의 형제 댓글에 연결된 foxboron 글을 보면 됨. 그건 환경 재현성, 또는 “결정적 빌드”에 더 가깝고 여전히 가치 있지만, 여기서 말하는 대상은 아님

  • 지금으로서는 래칫 방식처럼 들림. 기존에 한 번도 재현 가능하게 빌드된 적 없는 것들은 여전히 허용되는 건가?

    • 패키지가 재현 가능하게 빌드되지 않으면 다음 Debian 릴리스에 포함되지 않음. 즉 “한 번도 재현 가능하게 빌드된 적 없는” 패키지는 Debian unstable에는 남을 수 있지만, stable에 도달하지 않는 패키지를 Debian unstable에 계속 두는 것은 좋게 보지 않음. 다만 기계적으로 강제하는 규칙은 없는 것으로 앎
답변달기