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에 계속 두는 것은 좋게 보지 않음. 다만 기계적으로 강제하는 규칙은 없는 것으로 앎