Fedora의 패키지 99% 재현 가능 빌드를 목표로 하는 변화
(lwn.net)- Fedora는 전체 패키지의 99%를 재현 가능하게 만들기 위한 변화를 Fedora 43에서 추진 중임
- 기존 인프라 개선으로 90%까지 달성했으며, 나머지는 패키저가 버그로 인식하고 해결하도록 유도할 계획임
- 보안 강화와 패키지 품질 향상을 목표로 하며, 독립적 검증 도구 rebuilderd도 도입 예정임
오픈소스 빌드의 재현 가능성(Reproducible Builds) 개요
- 오픈소스 소프트웨어의 보안을 강화하고 무결성을 검증하기 위해 '재현 가능 빌드'가 중요해지고 있음
- 재현 가능 빌드는 동일한 소스 코드, 빌드 환경, 빌드 명령을 통해 누구나 동일한 결과물을 생성할 수 있는 빌드임
- Debian은 이 분야에서 10년 이상 앞서 있으며, 현재는 공식 라이브 CD도 재현 가능하게 제작 가능함
- Fedora는 재현 가능 빌드에 대한 작업을 최근에 시작했지만, Fedora 43 개발 주기에 전체 패키지의 99%를 재현 가능하게 만드는 제안을 검토 중임
Fedora와 Debian의 차이점
- Debian은 로컬에서 빌드한 패키지 업로드를 허용해 신뢰성이 낮을 수 있음
- Fedora는 모든 패키지를 중앙에서 강력하게 통제된 인프라에서 빌드함
- Fedora는
dist-git
이라는 Git 저장소에 소스 및 해시 정보 포함해 패키지 추적이 용이함
Fedora만의 재현 가능 빌드 정의
- Fedora는 Debian과 다른 정의를 사용함
- 서명(signature) 및 일부 메타데이터는 제외하고, RPM 파일의 실제 콘텐츠(payload)에 초점
- 이유는 RPM 포맷의 특성과 서명 방식, 빌드 시간(BUILDTIME) 및 빌드 호스트(BUILDHOST) 같은 정보가 포함되기 때문
- openSUSE는 BUILDHOST를
reproducible
로 설정하여 해결하고 있음
Fedora의 재현 가능 빌드를 향한 기술적 진전
- Fedora 38부터
SOURCE_DATE_EPOCH
을 이용해 파일의 수정 시간을 고정하는 변경을 적용함 - Fedora 41에서
add-determinism
이라는 Rust 기반 도구를 도입하여, 빌드된 파일의 메타데이터를 표준화함 - Debian은
strip-nondeterminism
이라는 Perl 라이브러리를 사용하지만, Fedora는 Perl 의존성을 피하기 위해 독자 도구를 선택함 - 현재까지 약 90%의 패키지 재현 가능성을 달성함
앞으로의 계획
- 남은 9%는 패키저들이 재현 불가능한 문제를 버그로 간주하고 수정하도록 유도할 계획
-
fedora-repro-build
유틸리티를 제공해 로컬에서 Koji 빌드를 재현 가능 여부 테스트 가능 -
rebuilderd
라는 독립 검증 시스템을 공개적으로 운영할 계획이며, 이는 패키지 메타데이터를 분석하고 재빌드를 통해 재현 가능성을 검증함 -
rebuilderd
는diffoscope
를 통해 차이점 리포트를 생성 가능함
패키징 가이드라인 및 품질 향상
- Fedora의 패키징 가이드라인은 "가능하면 재현 가능하게 빌드되어야 함"으로 업데이트될 예정
- 재현 가능 빌드는 보안뿐 아니라 패키지 품질 향상에도 기여함
- 예: 아키텍처 독립 패키지에서 하드웨어 종속성이 발견되면 이는 버그일 가능성 있음
재현 불가능한 예외 사례
- Haskell은 멀티스레드 빌드시 재현 불가, 수정 작업 진행 중
- Go는 디버그 파일
.gdb_index
가 일정하지 않아 재현 불가, 해결책 없음 - Linux 커널 모듈 서명에 일시적 키 사용, 관련 패치가 제안됨
커뮤니티 피드백
- Fedora 인프라 팀에서 rebuilderd의 위치 및 유지 관리에 대한 질문 제기
- rebuilderd를 Koji에 통합할 수 있는지 여부도 논의됨
- 독립적 검증을 위해 Koji 외 시스템 사용이 바람직하다는 의견도 있음
- 일부는 rebuilderd 대신 Copr를 활용하는 방안도 제안함
- 전반적으로는 기존 Fedora 도구와 통합성을 높이는 방향이 선호됨
향후 절차
- FESCo(Fedora Engineering Steering Committee)에 제안 티켓을 제출 예정
- 승인되면 Fedora 43 출시 목표인 10월까지 실행 작업을 본격화할 계획
- 최종 사용자들은 차이를 크게 느끼지 못하겠지만, 공급망 보안 측면에서 매우 가치 있는 변화임
fedora 팀은 항상 놀랍고 대부분의 결정이 옳은 방향으로 발전하려는 느낌을 줍니다. 매번 기여해주시는 모든분들께 감사한 마음으로 사용합니다.
여전히 리눅스커뮤니티에선 리눅스데스크탑 용으로 인기가 매우 높습니다.
서버용도의 배포판이 아니라서 리눅스데스크탑이 활발하지 않은 우리나라에선 그다지 인지도가 높지 않은 것 같습니다.
뭔가 리눅스 이야기가 반가워서 덧붙이게 되는데요..ㅎㅎ
우분투는 snap 도입 이후로 데스크탑진영에선 민심이 나락가기도 했고.. 유니티 de도 호불호가 크게 갈리고.. 배포주기가 너무 길어서 최신드라이버 지원도 잘 안돼서..
데스크탑리눅스를 고려중이시라면 정말 fedora 추천합니다.
Fedora 가 순정에 가까운 Gnome 을 사용하는데 Gnome도 최근 업데이트가 빵빵해서 정말 만족스러워요!
Hacker News 의견
- 길을 가면서 만난 친구가 진정한 보물임
- 정적으로 링크된 바이너리를 더 보고 싶음. 예를 들어, Python은 설치하고 작업하기가 악몽임
- 그들도 이 프로젝트에 참여하고 있는 것을 보니 좋음
- Haskell 패키지는 여러 스레드로 컴파일할 때 현재 재현 가능하지 않음. 하지만 이는 큰 문제가 아니라고 생각함. gcc 컴파일러는 멀티스레드 컴파일을 지원하지 않음. C 언어에서는 병렬 처리는 여러 번역 단위를 병렬로 컴파일하는 것에서 옴
- 이 진전을 보니 놀라움. 노력한 모든 사람들에게 찬사를 보냄
- 관련 뉴스로는 3월에 Debian bookworm 라이브 이미지가 완전히 재현 가능해졌다는 소식이 있음
- Fedora 사용자로서 이것이 실제로 나에게 무엇을 주는지 궁금함. 폐쇄적인 빌드를 위해서는 이해하지만 왜 필요한지 궁금함
- 재현 가능성은 프로파일 가이드 최적화와 상충됨. 특히 네트워킹 및 일관되지 않은 기타 IO를 포함하는 경우에 그러함
- 예! 더 많은 도구가 결정론적이기를 원함. 내 소망 목록의 최상위에는 Proxmox 설정이 있음