# Rust 기반 coreutils의 날짜 버그로 Ubuntu 25.10 자동 업데이트 중단

> Clean Markdown view of GeekNews topic #23898. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=23898](https://news.hada.io/topic?id=23898)
- GeekNews Markdown: [https://news.hada.io/topic/23898.md](https://news.hada.io/topic/23898.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-10-25T07:33:19+09:00
- Updated: 2025-10-25T07:33:19+09:00
- Original source: [lwn.net](https://lwn.net/Articles/1043103/)
- Points: 2
- Comments: 1

## Topic Body

- Ubuntu 25.10에서 **Rust로 작성된 coreutils(uutils)** 의 `date` 명령어 버그로 인해 일부 시스템의 **자동 업데이트 기능이 작동하지 않는 문제**가 발생  
- 이 버그는 **rust-coreutils 패키지 0.2.2-0ubuntu2 이하 버전**에서 발견되었으며, **0.2.2-0ubuntu2.1 이상 버전**에서 수정됨  
- 문제는 **클라우드 배포, 컨테이너 이미지, 데스크톱 및 서버 설치 환경** 모두에 영향을 미쳤으나, `apt` 명령어를 통한 **수동 업데이트에는 영향 없음**  
- Ubuntu는 이번 릴리스에서 **Rust 기반 유틸리티(uutils, sudo-rs)** 로의 전환을 시험 중이며, 이는 내년 **장기 지원(LTS) 버전 적용 가능성**을 평가하기 위한 과정  
- 이번 사건은 **Rust 전환 과정의 안정성 검증 필요성**을 보여주며, 향후 배포판의 보안 및 유지보수 전략에 중요한 시사점을 제공  

---

### Ubuntu 25.10 자동 업데이트 장애 개요
- Ubuntu 프로젝트는 **Rust 기반 uutils의 `date` 명령어 버그**로 인해 일부 시스템이 자동으로 업데이트를 확인하지 못하는 문제를 공식 발표  
  - 영향을 받은 시스템에는 **클라우드 배포 환경, 컨테이너 이미지, Ubuntu Desktop 및 Server 설치본**이 포함  
  - 자동 업데이트 확인이 실패해 **보안 패치 및 소프트웨어 갱신이 지연될 위험** 존재  
- Ubuntu 보안팀은 공지를 통해 **해결 방법(remediation instructions)** 을 제공  
  - 사용자는 **rust-coreutils 패키지를 0.2.2-0ubuntu2.1 이상 버전으로 업데이트**해야 문제 해결 가능  
  - 해당 버그는 **자동 업데이트 프로세스에만 영향을 미치며**, `apt` 명령어나 기타 수동 업데이트 도구에는 영향 없음  

### 버그의 원인과 영향 범위
- 문제의 원인은 **Rust로 재작성된 coreutils(uutils)** 의 `date` 명령어가 **시스템 시간 처리 과정에서 오류를 일으킨 것**으로 분석  
  - 이로 인해 자동 업데이트 스케줄러가 **정확한 날짜 계산에 실패**, 업데이트 확인 루틴이 중단됨  
- 영향 범위는 Ubuntu 25.10의 **모든 배포 형태**에 걸쳐 있으며, 특히 **자동화된 서버 환경 및 클라우드 인스턴스**에서 운영 중단 가능성 존재  
- Ubuntu는 이번 문제를 통해 **Rust 기반 시스템 유틸리티의 안정성 검증 절차 강화 필요성**을 인식  

### Rust 기반 유틸리티 전환(“Oxidize” 프로젝트)
- Ubuntu는 25.10 릴리스에서 **“oxidize” 프로젝트**를 추진, 기존 C 기반 coreutils를 **Rust 기반 uutils**로 교체하는 실험 진행  
  - 동시에 **sudo 명령어의 Rust 버전(sudo-rs)** 도 도입하여 보안성과 메모리 안전성 향상 목표  
- 이 프로젝트는 **2026년 4월 예정된 장기 지원(LTS) 릴리스**에 Rust 기반 유틸리티를 포함할 수 있을지 평가하기 위한 시험 단계  
- LWN은 이미 2025년 3월 해당 프로젝트를 다루며, **Rust 도입이 리눅스 배포판의 구조적 안정성에 미칠 영향**을 분석한 바 있음  

### 수정 버전 및 대응 지침
- Ubuntu 보안 공지에 따르면, **rust-coreutils 0.2.2-0ubuntu2 이하 버전**이 문제를 포함  
  - **0.2.2-0ubuntu2.1 이상 버전**으로 업데이트 시 버그가 해결됨  
- 사용자는 `apt update && apt upgrade` 명령을 통해 **패키지 수동 업데이트**를 수행 가능  
  - 자동 업데이트 기능이 복구되기 전까지는 **정기적인 수동 점검**이 권장됨  

### 시사점 및 향후 전망
- 이번 사건은 **Rust 전환 과정에서의 초기 불안정성**을 보여주는 사례로 평가  
  - 메모리 안전성과 보안성 향상을 위한 Rust 도입이 **기능적 안정성 검증**과 병행되어야 함을 시사  
- Ubuntu의 실험은 **리눅스 배포판 전반의 Rust 채택 흐름**을 가속할 가능성 있음  
- 향후 LTS 릴리스에서 Rust 기반 유틸리티가 안정적으로 통합될 경우, **시스템 보안 및 유지보수 효율성 향상**이 기대됨

## Comments



### Comment 45431

- Author: neo
- Created: 2025-10-25T07:33:20+09:00
- Points: 1

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

- 기존 coreutils에 개선이 필요할 정도로 문제가 있었는지 궁금함  
  - 아마도 **라이선스 문제** 때문일 가능성이 있음. 예전에 [이 댓글](https://news.ycombinator.com/item?id=38853429)에서도 그런 추측이 있었음  
  - OpenBSD 유지보수자 입장에서는, 특정 언어가 시스템 언어로 적합한지 판단하려면 coreutils를 그 언어로 구현해보는 게 필수라고 함  
    관련 글: [OpenBSD 메일링리스트](https://marc.info/?l=openbsd-misc&m=151233345723889&w=2)  
  - [CVE-2015-4042](https://www.cvedetails.com/cve/CVE-2015-4042/) 같은 보안 이슈 때문일 수도 있음  
  - Rust로 작성되지 않았다는 게 문제였던 것 같음. 그런데 **borrow checker**가 왜 date 버그를 잡지 못했는지 의문임  
  - 배경을 알고 싶다면 Ubuntu의 공식 글인 [Carefully but purposefully oxidising Ubuntu](https://discourse.ubuntu.com/t/carefully-but-purposefully-oxidising-ubuntu/56995)를 참고하면 됨  

- uutils에서의 **패치 링크**를 찾고 싶음  
  - [LWN 기사](https://lwn.net/Articles/1043123/)에 설명이 있음  
    핵심 버그는 `date -r <file>` 지원이 구현되지 않았는데 Ubuntu가 그 버전을 통합했다는 점임  
    명령이 `-r` 옵션을 조용히 무시하고 아무 일도 하지 않았음  
    관련 이슈: [#8621](https://github.com/uutils/coreutils/issues/8621), [PR #8630](https://github.com/uutils/coreutils/pull/8630)  
  - Ubuntu 버그 리포트는 [여기](https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bug/2127970)에 있음  
  - 문제의 근본은 Rust로 **재작성 프로젝트 자체의 존재**라고 생각함  
  - 실제 문제 설명이 부족한 게 아쉬움  
    마지막 커밋([링크](https://github.com/uutils/coreutils/commit/0047c7e66ffb579713d0673dec17875d7e6fbfeb))은 date 파싱을 GNU와 일치시키는 수정이었는데, 다른 댓글을 보니 원인은 그게 아닐 수도 있음  

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

- Ubuntu changelog를 보면 버그가 `date -r` 관련임  
  [changelog](https://launchpad.net/ubuntu/questing/+source/rust-coreutils/+changelog)와 [버그 리포트](https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bug/2127970), [이슈](https://github.com/uutils/coreutils/issues/8621), [PR](https://github.com/uutils/coreutils/pull/8630)을 보면  
  `date -r`이 파일 수정 시각을 출력해야 하는데, Rust 버전은 그냥 무시했음  
  이런 **기본 동작 누락**은 “안전한 대체품”을 표방하는 프로젝트로서는 실망스러움  
  - 만약 이 버전이 coreutils의 공식 테스트를 통과했다면, 오히려 **테스트 스위트가 불완전**하다는 뜻일 수도 있음  
  - 그래도 **버퍼 오버플로우**는 없었음!  

- [Ubuntu 보안 공지](https://lists.ubuntu.com/archives/ubuntu-security-announce/2025-October/009890.html) — 전형적인 사례 같음  

- Ubuntu 25.10은 **사용 불가능할 정도**라고 느꼈음. 비-LTS 버전에 대해 이렇게 말한 건 처음임  
  - 어떤 점이 그렇게 심각한지 구체적으로 설명해줄 수 있는지 궁금함  

- “수십 년간 검증된 C 유틸리티를 Rust로 다시 쓰는 건 장기적으로 좋을 수 있지만, 단기적 문제는 예측 가능했다”는 말에 공감함  
  하지만 “장기적”이란 게 얼마나 긴 기간을 의미하는지 의문임  
  FOSDEM 발표에서 uutils 개발자가 **잘못된 벤치마크**로 성능이 더 낫다고 주장했는데, 실제로는 locale 미지원 때문이었다는 점도 문제였음  
  관련 링크: [FOSDEM 발표](https://archive.fosdem.org/2025/schedule/event/fosdem-2025-6196-rewriting-the-future-of-the-linux-essential-packages-in-rust-/), [스레드1](https://desuarchive.org/g/thread/104831348/#q104831479), [스레드2](https://desuarchive.org/g/thread/104831348/#104831809)  
  - 하지만 이런 핵심 도구들도 결국 **여러 번의 재작성**을 거쳐온 결과물임. 너무 극단적으로 볼 필요는 없음  
  - locale 처리가 추가된 후에는 오히려 **성능이 향상**되었다는 [Phoronix 기사](https://www.phoronix.com/news/Rust-Coreutils-0.2)도 있음  
  - 이런 재작성 대신, 같은 노력으로 **형식 검증 시스템**을 구축했다면 보안 측면에서 더 나았을지도 모른다는 생각이 듦  
  - 오픈소스 프로젝트가 개인의 **명성 쌓기 수단**으로 이용되는 경우도 있음  
    핵심 유틸리티를 새로 작성하는 건 포트폴리오에 큰 이점이 되기 때문임  

- guided state-space exploration이나 **fuzzing의 최신 기술**이 궁금함  
  기존 구현이 있다면 fuzzer가 두 버전의 동작을 비교해 **화이트박스 검증**을 할 수 있을 것 같음  
  - 이런 경우 **property testing**이 잘 맞을 것 같음  
    전체 입력 공간에 대한 proptest를 작성하려면 많은 노력이 필요하지만, CLI 인자가 안정적이라면 충분히 가능함  
    man 페이지 같은 자료를 기반으로 자동 생성도 가능함  
    Rust에서는 `proptest` 크레이트를, CLI 차이 검증에는 Python의 **Hypothesis**를 외부 호출로 사용하는 게 좋을 듯함