Bug tanggal pada coreutils berbasis Rust menghentikan pembaruan otomatis Ubuntu 25.10

• Di Ubuntu 25.10, bug pada perintah date milik coreutils (uutils) yang ditulis dengan Rust menyebabkan fitur pembaruan otomatis tidak berfungsi di sebagian sistem
• Bug ini ditemukan pada paket rust-coreutils versi 0.2.2-0ubuntu2 atau lebih lama, dan telah diperbaiki pada versi 0.2.2-0ubuntu2.1 atau lebih baru
• Masalah ini memengaruhi deployment cloud, image container, serta lingkungan instalasi desktop dan server, tetapi pembaruan manual melalui perintah apt tidak terpengaruh
• Ubuntu sedang menguji peralihan ke utilitas berbasis Rust (uutils, sudo-rs) dalam rilis ini, sebagai bagian dari evaluasi untuk kemungkinan penerapan pada versi Long Term Support (LTS) tahun depan
• Insiden ini menunjukkan perlunya verifikasi stabilitas dalam proses transisi ke Rust dan memberi implikasi penting bagi strategi keamanan serta pemeliharaan distribusi ke depan

---

Ringkasan gangguan pembaruan otomatis Ubuntu 25.10

• Proyek Ubuntu secara resmi mengumumkan bahwa bug pada perintah date di uutils berbasis Rust menyebabkan sebagian sistem gagal memeriksa pembaruan secara otomatis
  • Sistem yang terdampak mencakup lingkungan deployment cloud, image container, serta instalasi Ubuntu Desktop dan Server
  • Kegagalan pemeriksaan pembaruan otomatis menimbulkan risiko tertundanya patch keamanan dan pembaruan perangkat lunak
• Tim keamanan Ubuntu memberikan instruksi pemulihan (remediation instructions) melalui pengumuman resminya
  • Pengguna perlu memperbarui paket rust-coreutils ke versi 0.2.2-0ubuntu2.1 atau lebih baru untuk menyelesaikan masalah
  • Bug ini hanya memengaruhi proses pembaruan otomatis, dan tidak berdampak pada perintah apt atau alat pembaruan manual lainnya

Penyebab bug dan cakupan dampaknya

• Penyebab masalah dianalisis berasal dari perintah date dalam coreutils (uutils) yang ditulis ulang dengan Rust yang menimbulkan kesalahan saat memproses waktu sistem
  • Akibatnya, scheduler pembaruan otomatis gagal menghitung tanggal secara akurat, sehingga rutinitas pemeriksaan pembaruan terhenti
• Cakupan dampaknya meliputi semua bentuk distribusi Ubuntu 25.10, terutama menimbulkan potensi gangguan operasional pada lingkungan server terotomatisasi dan instance cloud
• Melalui masalah ini, Ubuntu menyadari perlunya memperkuat prosedur verifikasi stabilitas untuk utilitas sistem berbasis Rust

Transisi ke utilitas berbasis Rust (proyek “Oxidize”)

• Dalam rilis 25.10, Ubuntu mendorong proyek “oxidize”, sebuah eksperimen untuk mengganti coreutils lama berbasis C dengan uutils berbasis Rust
  • Secara bersamaan, Ubuntu juga memperkenalkan versi Rust dari perintah sudo (sudo-rs) dengan tujuan meningkatkan keamanan dan memory safety
• Proyek ini merupakan tahap uji coba untuk mengevaluasi apakah utilitas berbasis Rust dapat dimasukkan ke dalam rilis Long Term Support (LTS) yang dijadwalkan pada April 2026
• LWN sebelumnya telah membahas proyek ini pada Maret 2025, dengan analisis mengenai dampak adopsi Rust terhadap stabilitas struktural distribusi Linux

Versi perbaikan dan panduan penanganan

• Menurut pengumuman keamanan Ubuntu, masalah ini terdapat pada rust-coreutils versi 0.2.2-0ubuntu2 atau lebih lama
  • Bug akan teratasi jika diperbarui ke versi 0.2.2-0ubuntu2.1 atau lebih baru
• Pengguna dapat melakukan pembaruan paket secara manual melalui perintah apt update && apt upgrade
  • Hingga fungsi pembaruan otomatis pulih, pemeriksaan manual secara berkala disarankan

Implikasi dan prospek ke depan

• Insiden ini dinilai sebagai contoh ketidakstabilan awal dalam proses transisi ke Rust
  • Ini menunjukkan bahwa adopsi Rust untuk meningkatkan memory safety dan keamanan harus berjalan beriringan dengan verifikasi stabilitas fungsional
• Eksperimen Ubuntu berpotensi mempercepat tren adopsi Rust di ekosistem distribusi Linux secara keseluruhan
• Jika utilitas berbasis Rust dapat diintegrasikan secara stabil dalam rilis LTS mendatang, hal ini diharapkan dapat meningkatkan keamanan sistem dan efisiensi pemeliharaan

[GN⁺]

Komentar Hacker News

• Menurut saya, menemukan masalah lebih awal seperti ini masih oke
  Selama dibereskan sebelum rilis LTS, seharusnya tidak masalah

  • Sebagai pengguna Ubuntu biasa, saya kurang yakin apakah ini benar-benar oke
    Kalau melihat grafik kompatibilitas pengujian uutils/coreutils, masih belum sepenuhnya matang
    Khususnya date hanya lulus 2 pengujian, 3 dilewati, dan 3 error
    Sulit menganggap kondisi seperti ini sudah siap produksi
  • Kalau mengelola banyak sistem, ada komponen tertentu yang terlalu kita percayai sampai saat ada masalah pun kita tidak langsung mencurigainya
    Bug seperti ini mungkin sepele bagi pengguna individu, tetapi bisa fatal di lingkungan skala besar
    Saya menghabiskan sepanjang hari untuk debugging dan akhirnya menemukan bahwa sistem mengirim data ke tempat yang secara eksplisit dilarang
    Akibatnya seluruh sistem berhenti, dan ketika alat yang diandalkan rusak, pengelolaannya jadi sangat sulit
    Kalau ini bukan ditulis dalam Rust, para pengembangnya mungkin sudah dihujani kritik besar-besaran
  • Tidak bisa dibilang oke kalau utilitas inti diganti dengan versi tulis ulang tanpa alasan yang jelas, lalu versinya begitu tidak stabil sampai distribusi stabil pun tidak bisa diperbarui dengan benar
  • Ucapan “memang begini cara menemukan isu” terdengar seperti gaya respons Microsoft /s

• Saya penasaran apakah coreutils lama memang cukup bermasalah sampai perlu diperbaiki

  • Mungkin karena masalah lisensi. Dulu ada spekulasi seperti itu juga di komentar ini
  • Dari sudut pandang pemelihara OpenBSD, untuk menilai apakah suatu bahasa cocok sebagai bahasa sistem, mengimplementasikan coreutils dalam bahasa itu adalah hal yang esensial
    Tulisan terkait: milis OpenBSD
  • Bisa juga karena isu keamanan seperti CVE-2015-4042
  • Sepertinya masalahnya adalah karena utilitas itu tidak ditulis dalam Rust. Tapi saya tetap heran kenapa borrow checker tidak menangkap bug date ini
  • Kalau ingin tahu latar belakangnya, lihat tulisan resmi Ubuntu Carefully but purposefully oxidising Ubuntu

• Saya ingin menemukan tautan patch di uutils

  • Ada penjelasannya di artikel LWN
    Bug intinya adalah dukungan date -r <file> belum diimplementasikan, tetapi Ubuntu tetap mengintegrasikan versi itu
    Perintah tersebut diam-diam mengabaikan opsi -r dan tidak melakukan apa pun
    Isu terkait: #8621, PR #8630
  • Laporan bug Ubuntu ada di sini
  • Menurut saya akar masalahnya adalah keberadaan proyek penulisan ulang dalam Rust itu sendiri
  • Agak disayangkan karena penjelasan masalah yang sebenarnya kurang memadai
    Commit terakhir (tautan) adalah perbaikan agar parsing date sesuai dengan GNU, tetapi dari komentar lain tampaknya penyebabnya mungkin bukan itu

• Komentar teratas lucu — katanya “nama rilis Ubuntu berikutnya akan menjadi Grateful Guinea-Pig”

• Dari changelog Ubuntu terlihat bahwa bug ini terkait date -r
  Kalau melihat changelog, laporan bug, isu, dan PR,
  date -r seharusnya menampilkan waktu modifikasi file, tetapi versi Rust malah mengabaikannya begitu saja
  Hilangnya perilaku dasar seperti ini mengecewakan untuk proyek yang mengklaim sebagai “pengganti yang aman”

  • Jika versi ini ternyata lolos pengujian resmi coreutils, itu justru bisa berarti test suite-nya tidak lengkap
  • Tapi setidaknya tidak ada buffer overflow!

• Pengumuman keamanan Ubuntu — terasa seperti contoh yang sangat khas

• Rasanya Ubuntu 25.10 sudah sampai tingkat nyaris tidak bisa dipakai. Ini pertama kalinya saya mengatakan hal seperti itu untuk versi non-LTS

  • Saya penasaran bisa dijelaskan lebih konkret bagian mana yang begitu parah

• Saya setuju dengan pendapat bahwa “menulis ulang utilitas C yang sudah teruji puluhan tahun ke Rust mungkin baik dalam jangka panjang, tetapi masalah jangka pendeknya sudah bisa diprediksi”
  Tetapi saya bertanya-tanya seberapa panjang sebenarnya yang dimaksud dengan “jangka panjang”
  Dalam presentasi FOSDEM, pengembang uutils mengklaim performanya lebih baik dengan benchmark yang keliru, padahal kenyataannya itu karena locale belum didukung
  Tautan terkait: presentasi FOSDEM, thread1, thread2

  • Tapi utilitas inti seperti ini juga pada akhirnya merupakan hasil dari berulang kali ditulis ulang. Jadi tidak perlu melihatnya terlalu ekstrem
  • Ada juga artikel Phoronix yang menyebut setelah penanganan locale ditambahkan, justru kinerjanya meningkat
  • Daripada penulisan ulang seperti ini, mungkin akan lebih baik dari sisi keamanan jika upaya yang sama dipakai untuk membangun sistem verifikasi formal
  • Ada juga kasus proyek open source dipakai sebagai sarana membangun reputasi pribadi
    Menulis ulang utilitas inti memberi nilai besar untuk portofolio

• Saya penasaran dengan guided state-space exploration atau teknik fuzzing terbaru
  Jika sudah ada implementasi lama, sepertinya fuzzer bisa membandingkan perilaku dua versi untuk melakukan verifikasi white-box

  • Untuk kasus seperti ini, rasanya property testing sangat cocok
    Menulis proptest untuk seluruh ruang input memang membutuhkan banyak usaha, tetapi jika argumen CLI stabil, itu cukup memungkinkan
    Bahkan mungkin bisa dibuat otomatis berdasarkan materi seperti man page
    Di Rust, sepertinya cocok memakai crate proptest, dan untuk memverifikasi perbedaan CLI, memakai Hypothesis dari Python melalui pemanggilan eksternal tampaknya ide yang bagus