# Debian은 재현 가능한 패키지를 제공해야 함 > Clean Markdown view of GeekNews topic #29378. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29378](https://news.hada.io/topic?id=29378) - GeekNews Markdown: [https://news.hada.io/topic/29378.md](https://news.hada.io/topic/29378.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-05-11T14:00:48+09:00 - Updated: 2026-05-11T14:00:48+09:00 - Original source: [lists.debian.org](https://lists.debian.org/debian-devel-announce/2026/05/msg00001.html) - Points: 1 - Comments: 2 ## Topic Body - Debian 릴리스 팀이 forky 주기 중간에 **재현 가능한 패키지** 제공을 결정함 - 마이그레이션 소프트웨어가 reproduce.debian.net에서 재현되지 않는 **새 패키지**를 차단함 - testing의 기존 패키지에 **재현성 퇴행**이 생겨도 마이그레이션이 차단됨 - binNMU에도 source-full 업로드처럼 **autopkgtest** 실행 기능이 추가됨 - loong64 추가와 multi-arch 재빌드로 **CI 대기열**이 커져 인내가 필요함 --- ### Debian 패키지 재현성 의무화 - Debian 릴리스 팀은 forky 릴리스 주기 중간 지점에서 Debian이 **재현 가능한 패키지**를 제공해야 한다고 결정함 - 이 결정은 [Reproducible Builds 프로젝트](https://reproducible-builds.org/)의 노력에 힘입은 것임 - 전날부터 마이그레이션 소프트웨어가 [reproduce.debian.net](https://reproduce.debian.net/)에서 재현되지 않는 **새 패키지**의 마이그레이션을 차단하도록 활성화됨 - testing에 이미 있는 기존 패키지에서 **재현성 퇴행**이 발생하는 경우에도 마이그레이션이 차단됨 ### 품질 보증과 업로더 책임 - ## testing binNMU의 autopkgtest 실행 - 올해 초 마이그레이션 소프트웨어에 **binNMU**도 source-full 업로드와 마찬가지로 autopkgtest를 실행하는 기능이 추가됨 - 이 기능은 대부분의 메인테이너 작업과 직접 관련이 크지 않을 수 있지만, 품질 보증을 강화하는 또 하나의 단계로 다뤄짐 - ## loong64 아키텍처 추가와 CI 대기열 증가 - 2주 전 아카이브에 새 아키텍처 [loong64](https://wiki.debian.org/Ports/loong64)가 추가됨 - Debian은 buildd에서 빌드된 바이너리만 마이그레이션하도록 허용하며, **multi-arch 요구사항** 때문에 모든 아키텍처에서 상당수 패키지를 다시 빌드해야 했음 - 앞서 추가된 binNMU 기능 때문에 현재 **CI 대기열**이 꽤 커졌으며, 릴리스 팀은 약간의 인내를 요청함 - ## 업로드 이후 후속 조치 - 소스 패키지 업로더는 해당 패키지가 마이그레이션되도록 보장할 책임이 있음 - 패키지가 역방향 테스트 의존성의 **autopkgtest 회귀**로 막혀 있고 그 의존성 업데이트가 필요하다면, 업로더가 적절한 RC 심각도의 버그를 제출해야 함 ## Comments ### Comment 57220 - Author: neo - Created: 2026-05-11T16:32:23+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48081245) - 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 :/ - 나는 잘 보임. 지나치게 민감한 방화벽이 봇으로 판단한 걸 수도 있음 어쨌든 Wayback Machine에 있음: [https://web.archive.org/web/20260510074120/https://lists.deb...]() ### Comment 57213 - Author: neo - Created: 2026-05-11T14:00:48+09:00 - Points: 1 ###### [Lobste.rs 의견들](https://lobste.rs/s/q0bvq9/debian_must_ship_reproducible_packages) - 보안 측면에서 좋은 변화임. 전환 과정은 번거로울 수 있지만, 최종적으로 전 세계 **Debian Linux 사용자**에게 더 높은 신뢰성을 제공하게 됨 - Debian 같은 프로젝트에 주는 핵심 이점이 뭔지 궁금함. 바이너리에 **백도어가 없다는 증거**를 모두가 가질 수 있게 하려는 건가? 즉, 유지관리자에게 요구되는 신뢰를 줄이고 악의적인 유지관리자 위험도 낮추는 효과인지 궁금함. 회의적인 건 아니고, Debian이 왜 여기에 그렇게 많은 시간을 쓰는지 100% 이해하지 못했음. 빌드를 재현 가능하게 만드는 일은 꽤 까다롭고 손이 많이 갈 것 같음 - 백도어뿐 아니라 일반적인 **변조나 수정** 여부도 확인할 수 있게 함. 이는 보안에도 도움이 되고 프로젝트 개발에도 이점이 있는데, 재현 가능하고 어느 정도 밀폐된 방식으로 빌드되는 패키지는 다른 개발자 환경에서 이상하게 깨질 가능성이 줄어듦 핵심은 출력 패키지를 만든 소스 코드가 정말 그 특정 소스 코드이며, 숨겨진 두 번째 소스 묶음이 아니라는 증거 산출물을 제공하는 것임. [the reproducible-builds org has a bit of a 'why' which puts it better than i can](https://reproducible-builds.org/docs/why/) 재현 가능한 빌드를 만드는 건 매우 어렵다. 예를 들어 [컴파일 파이프라인 안의 타임스탬프](https://reproducible-builds.org/docs/source-date-epoch/)도 차이를 만들고, [생성된 아카이브의 메타데이터](https://reproducible-builds.org/docs/archives/)도 마찬가지임. 이런 것들을 모두 제거해야 하고, 경우에 따라 패키지 자체가 아니라 CMake나 Go 컴파일러 같은 **상류 프로젝트 패치**가 필요함. 많은 경우 예전에는 이런 문제가 고려 대상조차 아니었기 때문에, 빌드 스택 전체에 걸쳐 작업이 들어가야 함. 다만 이 작업은 오래전부터 진행되어 와서, 하부 배관의 상당 부분은 이미 끝났거나 깊게 진행 중임 - 이것이 Debian의 최우선순위가 되어야 한다고는 생각하지 않지만, Debian은 그런 식으로 움직이지 않음. 사람들은 **자기가 하고 싶은 일**을 하고, 개인의 우선순위는 프로젝트 차원에서 합리적인 우선순위와 잘 맞지 않는 경우가 많음 - Debian이 말하는 **재현 가능성**은 NixOS 같은 곳에서 말하는 것과 같은 개념인가? - 아님. [NixOS is not reproducible](https://linderud.dev/blog/nixos-is-not-reproducible/)가 표준 참고 글임 - 재현 가능한 빌드를 프로젝트로 추적하는 배포판들은 대체로 같은 목표를 향해 감. [reproducible-builds.org](https://reproducible-builds.org/citests/)는 패키징 파이프라인에서 이를 적극적으로 작업 중인 프로젝트들을 추적함 NixOS도 **재현 가능한 빌드**를 작업 중이고, 기억이 맞다면 최소 ISO는 빌드와 런타임 모두 100% 재현 가능함. 하지만 흔히 NixOS에 대해 말하는 재현 가능성은 여기서 논의하는 “재현 가능한 빌드”가 아님. 이 스레드의 형제 댓글에 연결된 foxboron 글을 보면 됨. 그건 환경 재현성, 또는 “결정적 빌드”에 더 가깝고 여전히 가치 있지만, 여기서 말하는 대상은 아님 - 지금으로서는 **래칫 방식**처럼 들림. 기존에 한 번도 재현 가능하게 빌드된 적 없는 것들은 여전히 허용되는 건가? - 패키지가 재현 가능하게 빌드되지 않으면 다음 **Debian 릴리스**에 포함되지 않음. 즉 “한 번도 재현 가능하게 빌드된 적 없는” 패키지는 Debian unstable에는 남을 수 있지만, stable에 도달하지 않는 패키지를 Debian unstable에 계속 두는 것은 좋게 보지 않음. 다만 기계적으로 강제하는 규칙은 없는 것으로 앎