Rust-आधारित coreutils के date bug से Ubuntu 25.10 में automatic updates रुके

• Ubuntu 25.10 में Rust में लिखे गए coreutils (uutils) के date कमांड में bug की वजह से कुछ systems में automatic update फीचर काम नहीं कर रहा है
• यह bug rust-coreutils package version 0.2.2-0ubuntu2 या उससे नीचे में पाया गया, और 0.2.2-0ubuntu2.1 या उससे ऊपर में ठीक कर दिया गया
• समस्या का असर cloud deployments, container images, desktop और server installation environments सभी पर पड़ा, लेकिन apt कमांड के जरिए manual updates पर कोई असर नहीं है
• Ubuntu इस release में Rust-आधारित utilities (uutils, sudo-rs) पर स्विच करने का परीक्षण कर रहा है, ताकि अगले साल Long Term Support (LTS) version में संभावित लागूकरण का आकलन किया जा सके
• यह घटना दिखाती है कि Rust migration process की stability verification जरूरी है, और आगे distribution की security तथा maintenance strategy के लिए महत्वपूर्ण संकेत देती है

---

Ubuntu 25.10 automatic update outage का overview

• Ubuntu project ने आधिकारिक रूप से घोषणा की कि Rust-आधारित uutils के date कमांड bug की वजह से कुछ systems automatic updates की जांच नहीं कर पा रहे थे
  • प्रभावित systems में cloud deployment environments, container images, Ubuntu Desktop और Server installations शामिल हैं
  • automatic update checks fail होने से security patches और software updates में देरी का जोखिम है
• Ubuntu security team ने notice के जरिए समाधान निर्देश (remediation instructions) जारी किए
  • users को समस्या हल करने के लिए rust-coreutils package को version 0.2.2-0ubuntu2.1 या उससे ऊपर update करना होगा
  • यह bug सिर्फ automatic update process को प्रभावित करता है, apt कमांड या अन्य manual update tools को नहीं

bug का कारण और प्रभाव का दायरा

• समस्या का कारण Rust में दोबारा लिखे गए coreutils (uutils) के date कमांड द्वारा system time processing में error पैदा करना माना गया
  • इसके चलते automatic update scheduler सही date calculation करने में विफल रहा, और update check routine रुक गई
• प्रभाव का दायरा Ubuntu 25.10 के सभी deployment forms तक फैला है, खासकर automated server environments और cloud instances में operational disruption की संभावना रही
• Ubuntu ने इस समस्या के जरिए Rust-आधारित system utilities के लिए stability verification process मजबूत करने की जरूरत को पहचाना

Rust-आधारित utility migration ("Oxidize" project)

• Ubuntu 25.10 release में "oxidize" project को आगे बढ़ा रहा है, जिसके तहत मौजूदा C-आधारित coreutils को Rust-आधारित uutils से बदलने का प्रयोग किया जा रहा है
  • साथ ही sudo कमांड का Rust version (sudo-rs) भी लाया जा रहा है, ताकि security और memory safety बेहतर की जा सके
• यह project April 2026 के लिए निर्धारित Long Term Support (LTS) release में Rust-आधारित utilities को शामिल किया जा सकता है या नहीं, इसका evaluation stage है
• LWN ने March 2025 में इस project को पहले भी कवर किया था और Rust adoption का Linux distributions की structural stability पर प्रभाव का विश्लेषण किया था

fixed versions और response guidelines

• Ubuntu security advisory के अनुसार, rust-coreutils 0.2.2-0ubuntu2 या उससे नीचे के versions में यह समस्या मौजूद है
  • 0.2.2-0ubuntu2.1 या उससे ऊपर update करने पर bug ठीक हो जाता है
• users apt update && apt upgrade कमांड के जरिए package manual update कर सकते हैं
  • automatic update फीचर बहाल होने तक नियमित manual checks की सिफारिश की जाती है

implications और आगे की संभावना

• इस घटना को Rust migration process की शुरुआती अस्थिरता दिखाने वाले उदाहरण के रूप में देखा जा रहा है
  • memory safety और security बेहतर करने के लिए Rust adoption के साथ functional stability verification भी साथ-साथ होना चाहिए
• Ubuntu का यह प्रयोग पूरे Linux distribution ecosystem में Rust adoption की रफ्तार बढ़ा सकता है
• अगर आने वाले LTS release में Rust-आधारित utilities को स्थिर रूप से integrate किया जाता है, तो system security और maintenance efficiency में सुधार की उम्मीद है

[GN⁺]

Hacker News टिप्पणियाँ

• मुझे लगता है कि समस्याएँ जल्दी पकड़ना इस तरह से ठीक है
  बस LTS रिलीज़ से पहले चीज़ें ठीक हो जानी चाहिए

  • एक सामान्य Ubuntu यूज़र के तौर पर, मुझे पक्का नहीं कि यह सच में ठीक है
    uutils/coreutils का test compatibility graph देखें तो यह अभी पूरा नहीं है
    खासकर date सिर्फ 2 tests पास करता है, 3 skip होते हैं और 3 में errors हैं
    ऐसी स्थिति में इसे production-ready कहना मुश्किल है
  • जब आप कई systems चलाते हैं, तो कुछ components पर इतना भरोसा हो जाता है कि समस्या आने पर उन पर शक भी नहीं होता
    ऐसा bug किसी एक यूज़र के लिए मामूली हो सकता है, लेकिन बड़े environment में यह विनाशकारी हो सकता है
    आज पूरा दिन debugging के बाद पता चला कि system डेटा ऐसी जगह भेज रहा था जहाँ उसे साफ़ तौर पर जाने से रोका गया था
    नतीजतन पूरा system रुक गया, और जिन tools पर निर्भरता हो वे टूट जाएँ तो manage करना बहुत मुश्किल हो जाता है
    अगर यह Rust की जगह किसी और language में होता, तो developers को बहुत ज़्यादा आलोचना झेलनी पड़ती
  • अगर core utilities को बिना किसी साफ़ वजह के नए rewritten version से बदल दिया जाए, और वह इतना अस्थिर हो कि stable distro ठीक से update भी न कर पाए, तो इसे ठीक नहीं कहा जा सकता
  • “इसी तरह issues मिलते हैं” सुनने में कुछ Microsoft-स्टाइल प्रतिक्रिया जैसा लगता है /s

• सोच रहा हूँ कि क्या मौजूदा coreutils में सच में इतने issues थे कि सुधार की ज़रूरत पड़े

  • शायद वजह license issue हो सकती है। पहले इस comment में भी ऐसा अंदाज़ा लगाया गया था
  • OpenBSD maintainer के नज़रिए से, यह तय करने के लिए कि कोई भाषा system language के रूप में उपयुक्त है या नहीं, उस भाषा में coreutils implement करना ज़रूरी माना गया है
    संबंधित लेख: OpenBSD mailing list
  • शायद CVE-2015-4042 जैसे security issue भी वजह रहे हों
  • लगता है समस्या यह थी कि यह Rust में लिखा नहीं गया था। लेकिन फिर यह सवाल है कि borrow checker ने date bug क्यों नहीं पकड़ा
  • बैकग्राउंड जानना हो तो Ubuntu की आधिकारिक पोस्ट Carefully but purposefully oxidising Ubuntu देख सकते हैं

• मैं uutils में patch link ढूँढना चाहता हूँ

  • LWN लेख में इसका विवरण है
    मुख्य bug यह था कि date -r <file> support implement नहीं हुआ था, फिर भी Ubuntu ने वही version integrate कर लिया
    command -r option को चुपचाप ignore कर रही थी और कुछ भी नहीं कर रही थी
    संबंधित issue: #8621, PR #8630
  • Ubuntu bug report यहाँ है
  • मुझे लगता है असली समस्या Rust में rewrite project के अस्तित्व से ही शुरू होती है
  • अफ़सोस है कि वास्तविक समस्या का विवरण थोड़ा कम है
    आख़िरी commit(link) date parsing को GNU के अनुरूप करने वाला fix था, लेकिन दूसरे comments के अनुसार वजह शायद वह नहीं थी

• ऊपर वाला comment मज़ेदार था — “अगले Ubuntu release का नाम Grateful Guinea-Pig होगा”

• Ubuntu changelog देखने पर bug date -r से जुड़ा दिखता है
  changelog, bug report, issue, PR देखें तो
  date -r को file modification time दिखाना चाहिए, लेकिन Rust version ने उसे बस ignore कर दिया
  बुनियादी व्यवहार की ऐसी कमी ऐसे project के लिए निराशाजनक है जो खुद को “safe replacement” बताता है

  • अगर इस version ने coreutils के official tests पास कर लिए थे, तो शायद इसका मतलब है कि test suite ही अधूरी है
  • लेकिन कम से कम buffer overflow तो नहीं था!

• Ubuntu security notice — यह काफ़ी typical case लगता है

• मुझे Ubuntu 25.10 लगभग बेकार स्तर तक unusable लगा। किसी non-LTS version के बारे में मैंने पहली बार ऐसा कहा है

  • क्या आप थोड़ा विस्तार से बता सकते हैं कि कौन सी बातें इतनी गंभीर थीं?

• “दशकों से परखे गए C utilities को Rust में फिर से लिखना लंबी अवधि में अच्छा हो सकता है, लेकिन अल्पकालिक समस्याएँ अनुमानित थीं” — इससे सहमत हूँ
  लेकिन सवाल है कि “लंबी अवधि” से मतलब आख़िर कितना लंबा है
  FOSDEM प्रस्तुति में uutils developer ने गलत benchmark के आधार पर बेहतर performance का दावा किया था, जबकि असली वजह locale support का न होना था
  संबंधित links: FOSDEM प्रस्तुति, thread1, thread2

  • लेकिन ये core tools भी आख़िरकार कई बार rewrite होते-होते आज की स्थिति में पहुँचे हैं। इसे बहुत अतिवादी नज़र से देखने की ज़रूरत नहीं
  • locale handling जुड़ने के बाद तो उल्टा performance बेहतर होने की बात Phoronix लेख में भी है
  • कभी-कभी लगता है कि ऐसी rewrite की जगह, इसी मेहनत से formal verification system बनाया जाता तो security के लिहाज़ से बेहतर होता
  • open source projects कभी-कभी लोगों के प्रतिष्ठा बनाने के साधन की तरह भी इस्तेमाल होते हैं
    क्योंकि core utilities को नए सिरे से लिखना portfolio में बड़ा फ़ायदा देता है

• guided state-space exploration या fuzzing की नई तकनीकों के बारे में जानने की जिज्ञासा है
  अगर मौजूदा implementation मौजूद हो, तो fuzzer दोनों versions के व्यवहार की तुलना करके white-box verification कर सकता है

  • ऐसे case में property testing काफ़ी उपयुक्त लगती है
    पूरे input space के लिए proptest लिखना मेहनत का काम है, लेकिन अगर CLI arguments स्थिर हों तो यह काफ़ी संभव है
    man page जैसी सामग्री के आधार पर इसे auto-generate भी किया जा सकता है
    Rust में proptest crate, और CLI differences की जाँच के लिए Python की Hypothesis को external invocation के साथ उपयोग करना अच्छा रहेगा