Hacker News 의견

• 나는 이런 식으로 문제를 조기에 발견하는 게 괜찮다고 생각함
  LTS 릴리스 전에만 정리된다면 문제없음

  • 나는 평범한 Ubuntu 사용자로서 이게 괜찮은지는 잘 모르겠음
    uutils/coreutils의 테스트 호환성 그래프를 보면 아직 완전하지 않음
    특히 date는 테스트 2개만 통과하고 3개는 건너뛰고 3개는 오류임
    이런 상태로 프로덕션 준비 완료라고 보기 어렵다고 생각함
  • 시스템 여러 대를 운영하다 보면 일부 구성요소는 너무 신뢰해서 문제 발생 시 의심조차 안 하게 됨
    이런 버그는 개별 사용자에겐 사소할 수 있지만, 대규모 환경에서는 치명적임
    오늘 하루 종일 디버깅하다가 결국 시스템이 명시적으로 금지된 곳으로 데이터를 보내고 있었음을 발견했음
    결과적으로 시스템 전체가 멈췄고, 의존하던 도구가 깨지면 관리가 정말 힘들어짐
    만약 Rust가 아닌 다른 언어였다면 개발자들이 엄청난 비난을 받았을 것임
  • 핵심 유틸리티가 명확한 이유 없이 새로 작성된 버전으로 교체되고, 그게 너무 불안정해서 안정 배포판이 제대로 업데이트도 못 하는 상황이라면 괜찮다고 할 수 없음
  • “이슈를 이렇게 찾는 거야”라는 말이 마치 Microsoft식 대응처럼 들림 /s

• 기존 coreutils에 개선이 필요할 정도로 문제가 있었는지 궁금함

  • 아마도 라이선스 문제 때문일 가능성이 있음. 예전에 이 댓글에서도 그런 추측이 있었음
  • OpenBSD 유지보수자 입장에서는, 특정 언어가 시스템 언어로 적합한지 판단하려면 coreutils를 그 언어로 구현해보는 게 필수라고 함
    관련 글: OpenBSD 메일링리스트
  • CVE-2015-4042 같은 보안 이슈 때문일 수도 있음
  • Rust로 작성되지 않았다는 게 문제였던 것 같음. 그런데 borrow checker가 왜 date 버그를 잡지 못했는지 의문임
  • 배경을 알고 싶다면 Ubuntu의 공식 글인 Carefully but purposefully oxidising Ubuntu를 참고하면 됨

• uutils에서의 패치 링크를 찾고 싶음

  • LWN 기사에 설명이 있음
    핵심 버그는 date -r <file> 지원이 구현되지 않았는데 Ubuntu가 그 버전을 통합했다는 점임
    명령이 -r 옵션을 조용히 무시하고 아무 일도 하지 않았음
    관련 이슈: #8621, PR #8630
  • Ubuntu 버그 리포트는 여기에 있음
  • 문제의 근본은 Rust로 재작성 프로젝트 자체의 존재라고 생각함
  • 실제 문제 설명이 부족한 게 아쉬움
    마지막 커밋(링크)은 date 파싱을 GNU와 일치시키는 수정이었는데, 다른 댓글을 보니 원인은 그게 아닐 수도 있음

• 상위 댓글이 웃겼음 — “다음 Ubuntu 릴리스 이름은 Grateful Guinea-Pig일 것”이라고 함

• Ubuntu changelog를 보면 버그가 date -r 관련임
  changelog와 버그 리포트, 이슈, PR을 보면
  date -r이 파일 수정 시각을 출력해야 하는데, Rust 버전은 그냥 무시했음
  이런 기본 동작 누락은 “안전한 대체품”을 표방하는 프로젝트로서는 실망스러움

  • 만약 이 버전이 coreutils의 공식 테스트를 통과했다면, 오히려 테스트 스위트가 불완전하다는 뜻일 수도 있음
  • 그래도 버퍼 오버플로우는 없었음!

• Ubuntu 보안 공지 — 전형적인 사례 같음

• Ubuntu 25.10은 사용 불가능할 정도라고 느꼈음. 비-LTS 버전에 대해 이렇게 말한 건 처음임

  • 어떤 점이 그렇게 심각한지 구체적으로 설명해줄 수 있는지 궁금함

• “수십 년간 검증된 C 유틸리티를 Rust로 다시 쓰는 건 장기적으로 좋을 수 있지만, 단기적 문제는 예측 가능했다”는 말에 공감함
  하지만 “장기적”이란 게 얼마나 긴 기간을 의미하는지 의문임
  FOSDEM 발표에서 uutils 개발자가 잘못된 벤치마크로 성능이 더 낫다고 주장했는데, 실제로는 locale 미지원 때문이었다는 점도 문제였음
  관련 링크: FOSDEM 발표, 스레드1, 스레드2

  • 하지만 이런 핵심 도구들도 결국 여러 번의 재작성을 거쳐온 결과물임. 너무 극단적으로 볼 필요는 없음
  • locale 처리가 추가된 후에는 오히려 성능이 향상되었다는 Phoronix 기사도 있음
  • 이런 재작성 대신, 같은 노력으로 형식 검증 시스템을 구축했다면 보안 측면에서 더 나았을지도 모른다는 생각이 듦
  • 오픈소스 프로젝트가 개인의 명성 쌓기 수단으로 이용되는 경우도 있음
    핵심 유틸리티를 새로 작성하는 건 포트폴리오에 큰 이점이 되기 때문임

• guided state-space exploration이나 fuzzing의 최신 기술이 궁금함
  기존 구현이 있다면 fuzzer가 두 버전의 동작을 비교해 화이트박스 검증을 할 수 있을 것 같음

  • 이런 경우 property testing이 잘 맞을 것 같음
    전체 입력 공간에 대한 proptest를 작성하려면 많은 노력이 필요하지만, CLI 인자가 안정적이라면 충분히 가능함
    man 페이지 같은 자료를 기반으로 자동 생성도 가능함
    Rust에서는 proptest 크레이트를, CLI 차이 검증에는 Python의 Hypothesis를 외부 호출로 사용하는 게 좋을 듯함