Rust tabanlı coreutils tarih hatası Ubuntu 25.10 otomatik güncellemelerini durdurdu

• Ubuntu 25.10'da Rust ile yazılmış coreutils'in (uutils) date komutundaki bir hata nedeniyle bazı sistemlerde otomatik güncelleme işlevinin çalışmaması sorunu ortaya çıktı
• Bu hata rust-coreutils paketinin 0.2.2-0ubuntu2 ve altı sürümlerinde tespit edildi; 0.2.2-0ubuntu2.1 ve üzeri sürümlerde düzeltildi
• Sorun bulut dağıtımları, konteyner imajları, masaüstü ve sunucu kurulum ortamlarını etkiledi; ancak apt komutu üzerinden yapılan manuel güncellemeler etkilenmedi
• Ubuntu bu sürümde Rust tabanlı yardımcı araçlara (uutils, sudo-rs) geçişi deniyor; amaç bunun gelecek yılki uzun süreli destekli (LTS) sürümde uygulanabilirliğini değerlendirmek
• Bu olay, Rust geçiş sürecinde kararlılık doğrulamasının gerekliliğini gösteriyor ve dağıtımların gelecekteki güvenlik ile bakım stratejileri açısından önemli çıkarımlar sunuyor

---

Ubuntu 25.10 otomatik güncelleme arızasına genel bakış

• Ubuntu projesi, Rust tabanlı uutils içindeki date komutu hatası nedeniyle bazı sistemlerin güncellemeleri otomatik olarak denetleyemediğini resmen duyurdu
  • Etkilenen sistemler arasında bulut dağıtım ortamları, konteyner imajları, Ubuntu Desktop ve Server kurulumları yer alıyor
  • Otomatik güncelleme denetiminin başarısız olması, güvenlik yamaları ve yazılım güncellemelerinin gecikmesi riskini doğuruyor
• Ubuntu güvenlik ekibi, duyuruda çözüm adımlarını (remediation instructions) paylaştı
  • Kullanıcıların sorunu çözmek için rust-coreutils paketini 0.2.2-0ubuntu2.1 veya daha yeni bir sürüme güncellemesi gerekiyor
  • İlgili hata yalnızca otomatik güncelleme sürecini etkiliyor; apt komutu ya da diğer manuel güncelleme araçları etkilenmiyor

Hatanın nedeni ve etki kapsamı

• Sorunun nedeni, Rust ile yeniden yazılan coreutils'in (uutils) date komutunun sistem zamanı işleme sürecinde hata üretmesi olarak analiz edildi
  • Bunun sonucunda otomatik güncelleme zamanlayıcısı doğru tarih hesaplaması yapamadı ve güncelleme denetimi rutini durdu
• Etki alanı Ubuntu 25.10'un tüm dağıtım biçimlerine yayılıyor; özellikle otomasyonlu sunucu ortamları ve bulut örneklerinde hizmet kesintisi riski bulunuyor
• Ubuntu bu olayla birlikte, Rust tabanlı sistem yardımcı araçları için kararlılık doğrulama sürecini güçlendirme gereğini fark etti

Rust tabanlı yardımcı araçlara geçiş ("Oxidize" projesi)

• Ubuntu, 25.10 sürümünde "oxidize" projesini ilerletiyor ve mevcut C tabanlı coreutils'i Rust tabanlı uutils ile değiştirmeyi deneyimliyor
  • Aynı zamanda sudo komutunun Rust sürümü olan sudo-rs de devreye alınarak güvenlik ve bellek güvenliğinin artırılması hedefleniyor
• Bu proje, Nisan 2026'da planlanan uzun süreli destekli (LTS) sürümde Rust tabanlı yardımcı araçların yer alıp alamayacağını değerlendirmek için bir test aşaması niteliğinde
• LWN, bu projeyi daha önce Mart 2025'te ele almış ve Rust benimsenmesinin Linux dağıtımlarının yapısal kararlılığı üzerindeki etkisini analiz etmişti

Düzeltme sürümü ve yanıt yönergeleri

• Ubuntu güvenlik duyurusuna göre sorun, rust-coreutils 0.2.2-0ubuntu2 ve altı sürümlerde bulunuyor
  • 0.2.2-0ubuntu2.1 ve üzeri sürümlere güncelleme yapıldığında hata gideriliyor
• Kullanıcılar apt update && apt upgrade komutuyla paketleri manuel olarak güncelleyebilir
  • Otomatik güncelleme işlevi geri gelene kadar düzenli manuel kontrol öneriliyor

Çıkarımlar ve ileriye dönük görünüm

• Bu olay, Rust'a geçiş sürecindeki erken dönem kararsızlığın bir örneği olarak değerlendiriliyor
  • Bellek güvenliği ve güvenliği artırmak için Rust'ın benimsenmesinin, işlevsel kararlılık doğrulamasıyla birlikte yürütülmesi gerektiğine işaret ediyor
• Ubuntu'nun deneyi, Linux dağıtımları genelinde Rust benimseme eğilimini hızlandırabilir
• Gelecekteki LTS sürümlerinde Rust tabanlı yardımcı araçlar kararlı biçimde entegre edilirse, sistem güvenliği ve bakım verimliliğinde artış beklenebilir

[GN⁺]

Hacker News yorumu

• Bence sorunların erken tespit edilmesi bu şekilde fena değil
  Yeter ki LTS sürümünden önce toparlanmış olsun

  • Sıradan bir Ubuntu kullanıcısı olarak bunun gerçekten sorun olup olmadığını pek bilmiyorum
    uutils/coreutils test uyumluluk grafiğine bakınca hâlâ tamamlanmış görünmüyor
    Özellikle date yalnızca 2 testi geçiyor, 3 testi atlıyor ve 3 testte hata veriyor
    Bu durumda buna prodüksiyona hazır demek zor
  • Birden fazla sistem işletince bazı bileşenlere o kadar fazla güveniyorsunuz ki sorun çıktığında onlardan şüphe bile etmiyorsunuz
    Bu tür hatalar tekil kullanıcılar için küçük görünebilir ama büyük ölçekli ortamlarda yıkıcı olabilir
    Bugün bütün gün debug yaptıktan sonra sistemin açıkça yasaklanmış bir yere veri gönderdiğini fark ettim
    Sonuçta tüm sistem durdu ve bel bağladığınız araçlar bozulunca yönetmek gerçekten zorlaşıyor
    Eğer bu Rust yerine başka bir dil olsaydı geliştiriciler muhtemelen ağır eleştiri alırdı
  • Temel yardımcı araçlar ortada net bir gerekçe olmadan yeniden yazılmış sürümlerle değiştiriliyorsa ve bunlar da o kadar istikrarsızsa ki kararlı dağıtım düzgün güncellenemiyorsa, buna iyi diyemeyiz
  • “Sorunlar işte böyle bulunur” sözü kulağa biraz Microsoft usulü tepki gibi geliyor /s

• Mevcut coreutils’in gerçekten iyileştirme gerektirecek kadar sorunlu olup olmadığını merak ediyorum

  • Muhtemelen sebep lisans sorunları olabilir. Daha önce şu yorumda da böyle bir tahmin vardı
  • OpenBSD bakımcılarının bakış açısından, bir dilin sistem dili olmaya uygun olup olmadığını anlamak için coreutils’i o dilde uygulamak neredeyse şart sayılıyor
    İlgili yazı: OpenBSD e-posta listesi
  • CVE-2015-4042 gibi güvenlik sorunları da nedenlerden biri olabilir
  • Sorun galiba Rust ile yazılmamış olmasıydı. Ama borrow checker neden date hatasını yakalayamadı, onu merak ediyorum
  • Arka planı merak edenler Ubuntu’nun resmi yazısı olan Carefully but purposefully oxidising Ubuntu’ya bakabilir

• uutils tarafındaki yama bağlantısını bulmak istiyorum

  • LWN makalesinde açıklanıyor
    Asıl hata, date -r <file> desteğinin hiç uygulanmamış olmasına rağmen Ubuntu’nun bu sürümü entegre etmiş olması
    Komut -r seçeneğini sessizce yok sayıyor ve hiçbir şey yapmıyordu
    İlgili konu: #8621, PR #8630
  • Ubuntu hata raporu burada
  • Bence asıl sorun Rust ile yeniden yazma projesinin bizzat varlığı
  • Gerçek sorunun yeterince açıklanmamış olması üzücü
    Son commit (bağlantı) date ayrıştırmasını GNU ile uyumlu hâle getiren bir düzeltmeydi, ama diğer yorumlara bakılırsa neden bu olmayabilir

• Üstteki yorum komikti — “bir sonraki Ubuntu sürümünün adı Grateful Guinea-Pig olacak” demişler

• Ubuntu changelog’una bakılırsa hata date -r ile ilgili
  changelog, hata raporu, issue ve PR incelendiğinde
  date -r komutunun dosya değişiklik zamanını yazdırması gerekirken Rust sürümü bunu tamamen yok saymış
  Böyle temel bir davranış eksikliği, kendini “güvenli alternatif” diye tanıtan bir proje için hayal kırıklığı yaratıyor

  • Eğer bu sürüm gerçekten coreutils’in resmi testlerini geçtiyse, bu daha çok test paketinin eksik olduğuna işaret ediyor olabilir
  • Ama en azından buffer overflow yoktu!

• Ubuntu güvenlik duyurusu — tipik bir örnek gibi görünüyor

• Ubuntu 25.10 bana kullanılamayacak kadar kötü geldi. Bunu ilk kez LTS olmayan bir sürüm için söylüyorum

  • Hangi açıdan bu kadar kötü olduğunu biraz daha somut anlatabilir misin?

• “On yıllardır sınanmış C yardımcı araçlarını Rust ile yeniden yazmak uzun vadede iyi olabilir ama kısa vadeli sorunlar öngörülebilirdi” görüşüne katılıyorum
  Ama “uzun vade”nin ne kadar uzun bir süre anlamına geldiğini merak ediyorum
  FOSDEM sunumunda uutils geliştiricisi hatalı benchmark’larla daha iyi performans iddia etmişti; oysa bunun asıl sebebi locale desteğinin olmamasıydı
  İlgili bağlantılar: FOSDEM sunumu, başlık1, başlık2

  • Ama bu temel araçlar da sonuçta birden çok yeniden yazımın ürünü. Buna aşırı uçtan bakmamak lazım
  • locale işleme eklendikten sonra aslında performansın arttığını söyleyen bir Phoronix haberi de var
  • Böyle yeniden yazımlar yerine aynı emekle bir biçimsel doğrulama sistemi kurulsaydı güvenlik açısından daha iyi olabilirdi diye düşünüyorum
  • Açık kaynak projeler bazen kişisel itibar oluşturma aracı olarak da kullanılabiliyor
    Temel yardımcı araçları baştan yazmak portföy açısından büyük bir artı çünkü

• guided state-space exploration ya da fuzzing’in güncel teknikleri ilgimi çekiyor
  Elde mevcut bir uygulama varken, fuzzer’ın iki sürümün davranışını karşılaştırarak white-box doğrulama yapması mümkün gibi görünüyor

  • Böyle durumlarda property testing iyi uyum sağlayabilir
    Tüm girdi uzayı için proptest yazmak çok emek gerektirir ama CLI argümanları sabitse gayet yapılabilir
    man sayfaları gibi kaynaklara dayanarak otomatik üretim de mümkün olabilir
    Rust tarafında proptest crate’ini, CLI farklarını doğrulamak içinse harici çağrıyla Python’daki Hypothesis’ı kullanmak mantıklı görünüyor