Hacker News 의견

• NixOS와 재현 가능한 빌드가 xz 백도어를 탐지하지 못했음. NixOS는 악성 xz 빌드를 배포했지만, NixOS를 목표로 한 것이 아니었기 때문에 문제는 없었음

  • NixOS 개발자는 백도어가 드러났을 때 악성 xz 버전이 사용자에게 배포된 것을 보고 놀랐음
  • 이론과 현실은 다르며, xz가 가능했던 이유는 기술적 취약점이 아닌 '현실 세계'의 문제였음. 소프트웨어로 현실 세계를 패치할 수 없음을 인식하는 데 어려움이 있음

• 저자는 이번 사건에만 집중하고 있는 것 같음. Jiatan 사건은 단일 사례이며, 다른 시나리오에서도 방어가 실패할 수 있음

  • NixOS 사용자로서 NixOS가 이를 잡아내지 못했을 가능성이 높다고 생각함. 증거가 없으면 NixOS에 신뢰를 두는 것은 어리석음

• NixOS는 xz 백도어가 RedHat과 Debian을 목표로 했기 때문에 관련이 없음. 아이러니하게도 백도어는 Microsoft 직원에 의해 발견됨

• 기사에서는 배포판이 전통적인 설치용 tarball 대신 VCS(예: Github)에서 직접 소스 코드를 가져와야 한다고 언급함

  • 그러나 악의적인 유지보수자가 소스 코드 저장소에 직접 바이너리 블롭을 추가할 수 있음
  • 저자는 Github가 코드를 검증하는 것처럼 신뢰할 수 있다고 제안하지만, 실제로 Github는 코드를 검증하지 않음

• NixOS가 예방할 수 있었던 사건에 집중하려면 CrowdStrike 사건에 집중해야 함. 어제의 설정으로 부팅할 수 있었다면 대부분의 문제를 완화할 수 있었음

• NixOS는 소스에서 모든 것을 컴파일하고, 사용된 소스가 변조되지 않았음을 암호학적으로 검증하며, 패키지 간 버전 종속성을 가짐. Debian도 재현 가능한 빌드를 가짐

  • 문제는 빌드 시스템이 소스에서 빌드하기 전에 사전 컴파일된 객체 파일을 제거하지 않았다는 것임. 소스 코드를 아무도 확인하지 않으면 백도어를 추가할 수 있으며, NixOS나 다른 배포판도 이를 막을 수 없음

• "할 수 있었다"는 것은 증명되지 않았음을 의미하며, 실제로 그들은 이를 배포했음

• 훌륭한 설명적 분석. 잘못된, 오해를 불러일으키는 제목, 아마도 "기술적으로 정확"하지만, "백도어가 있는" 의미로 최선임

  • 빌드 매니저 도구의 필요성과 사용을 강조하며, 빌드 과정에서 파일이 파일에 영향을 미치는 인과 추적 그래프를 명시적으로 만들고, 그 그래프를 강제하거나 이전 추적 그래프와의 편차를 보고하는 방법을 구축해야 함

• Jia Tan의 PR이 승인되었다면, 악성 아티팩트가 tarball과 마찬가지로 Github 릴리스로 쉽게 갈 수 있었음. Github 릴리스가 보안 완화라는 점을 이해하기 어려움

• 릴리스 tarball이 소스와 다르다는 점

  • 유지보수자가 제공한 tarball이 원본 소스 코드에서 정직하게 생성되었다면, 어떻게 다른 버전 등이 문제가 되는지 이해하기 어려움
  • 생성된 tarball이 소스 코드 자체에서 생성될 수 있도록 하고, 아무것도 제외하지 말고, git add & commit을 해야 함. 이 경우에도 커밋 기록을 확인해야 하며, 육안으로는 무해했기 때문에 어떻게 검증할 수 있는지 의문임
  • 유지보수된 tarball이 소유자의 소스 코드에서 생성되고 Github에 없으면 문제가 됨

• 독이 든 테스트 파일을 푸시하는 것 이상의 문제가 있었지만, Nix가 이를 어떻게 예방할 수 있었는지 이해하기 어려움

  • 유명 프로젝트가 리더를 변경했다면, 커밋을 주의 깊게 보고 누가 리더인지 확인해야 할 것임

• 기사를 잘못 이해했는지, 놓친 것이 있는지 궁금함