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는 Debian의 도움을 받아 그걸 달성했음. 제대로 이해했다면 NetBSD가 더 열심히 해서라기보다 문제가 더 쉬웠던 것임. 패키지가 더 적고 변경도 덜 됨. 아직도 CVS를 쓰니 “안정성”이라는 말로는 부족할 정도임
참고로 Debian 패키지 대부분은 재현 가능한 빌드임. 그렇지 않은 것들, 대략 5%쯤 되는 패키지는 여기 그래프에서 주황색으로 표시됨: https://wiki.debian.org/ReproducibleBuilds
자랑을 하자면 stagex는 작년에 100% 전체 소스 부트스트랩 기반의 결정적이고 격리된 빌드를 처음 달성했고, 매 릴리스마다 서로 다른 유지보수자가 각자 하드웨어에서 수행한 여러 개의 서명된 재현을 의무화한 것도 처음임
Debian도 많이 발전했지만, Debian이 재현 가능하다고 할 때는 자기 빌드를 위해 서드파티 바이너리를 가져온다는 뜻임. 우리가 재현 가능하다고 할 때는 전체 소프트웨어 공급망 끝까지 100% 소스 코드에서 부트스트랩한다는 뜻임
이 차이는 중요하다고 봄 https://stagex.tools
요즘 왜 이게 이슈가 되는지 궁금함. 임베디드 기기에 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
:/
Hacker News 의견들
Debian과 자유 소프트웨어 세계에 큰 성과임
다만 이 필요성이 이해되기까지는 시간이 꽤 걸렸음. 2007년에 debian-devel에서 이게 필요하다고 말했을 때도 엄청난 시간 낭비라는 답을 들었고, 실제로 여기까지 오려면 많은 사람의 막대한 작업이 필요했지만 충분히 그럴 가치가 있었음
“그럴 가치가 있었다”는 말은 맞지 않다고 봄. Debian 기여 장벽만 더 높이는 일이고, 이미 Debian 기여가 어렵다고 불평하는 사람을 많이 봤음. 예전에는 “패키지들이 서로 잘 맞물리도록 온갖 검증과 견제가 필요하다”고 옹호했지만, 이건 별 이유 없이 어렵게 만들고 이득은 작은 단계로 보임
https://wiki.debian.org/ReproducibleBuilds에 정보가 더 있음. 일부는 오래됐지만, CI에서 빌드되는 패키지 수와 그중 재현 가능한 빌드가 얼마나 되는지 보여주는 차트도 있음
주황색은 FTBR, 즉 “재현 가능하게 빌드 실패”를 뜻함. 차트에서 숫자를 읽는 데 익숙하진 않지만 대략 몇 퍼센트, 4~5% 정도로 추정함
좋은 일임. NetBSD는 2017년부터 완전히 재현 가능한 빌드를 갖췄음. https://blog.netbsd.org/tnf/entry/netbsd_fully_reproducible_...
참고로 Debian 패키지 대부분은 재현 가능한 빌드임. 그렇지 않은 것들, 대략 5%쯤 되는 패키지는 여기 그래프에서 주황색으로 표시됨: https://wiki.debian.org/ReproducibleBuilds
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...