Debian को पुनरुत्पादनीय पैकेज उपलब्ध कराने होंगे

 (lists.debian.org)
1 पॉइंट द्वारा GN⁺ 5 시간 전 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • Debian रिलीज़ टीम ने forky चक्र के मध्य में पुनरुत्पादनीय पैकेज उपलब्ध कराने का निर्णय लिया
  • माइग्रेशन सॉफ़्टवेयर reproduce.debian.net पर पुनरुत्पादित न होने वाले नए पैकेजों को ब्लॉक करता है
  • testing के मौजूदा पैकेजों में पुनरुत्पादनीयता रिग्रेशन होने पर भी माइग्रेशन रोका जाता है
  • binNMU में भी source-full upload की तरह autopkgtest चलाने की सुविधा जोड़ी गई है
  • loong64 के जुड़ने और multi-arch rebuild के कारण CI कतार बढ़ गई है, इसलिए धैर्य की आवश्यकता है

Debian पैकेज पुनरुत्पादनीयता अनिवार्य

  • Debian रिलीज़ टीम ने forky रिलीज़ चक्र के मध्य बिंदु पर यह तय किया कि Debian को पुनरुत्पादनीय पैकेज उपलब्ध कराने होंगे
  • यह निर्णय Reproducible Builds project के प्रयासों से संभव हुआ है
  • कल से माइग्रेशन सॉफ़्टवेयर को इस तरह सक्रिय किया गया है कि वह reproduce.debian.net पर पुनरुत्पादित न होने वाले नए पैकेजों के माइग्रेशन को रोक दे
  • testing में पहले से मौजूद पैकेजों में पुनरुत्पादनीयता रिग्रेशन आने पर भी माइग्रेशन ब्लॉक किया जाता है

गुणवत्ता आश्वासन और uploader की ज़िम्मेदारी

  • testing binNMU के autopkgtest चलाना

    • इस साल की शुरुआत में माइग्रेशन सॉफ़्टवेयर में binNMU के लिए भी source-full upload की तरह autopkgtest चलाने की सुविधा जोड़ी गई
    • यह सुविधा अधिकतर maintainers के रोज़मर्रा के काम से सीधे जुड़ी न हो, फिर भी इसे गुणवत्ता आश्वासन को मज़बूत करने के एक और कदम के रूप में देखा जा रहा है

  • loong64 architecture जुड़ना और CI कतार बढ़ना

    • दो हफ्ते पहले archive में नया architecture loong64 जोड़ा गया
    • Debian केवल buildd पर बने binaries के माइग्रेशन की अनुमति देता है, और multi-arch आवश्यकताओं के कारण सभी architectures पर काफ़ी पैकेजों को फिर से build करना पड़ा
    • पहले जोड़ी गई binNMU सुविधा की वजह से इस समय CI कतार काफ़ी बड़ी हो गई है, और रिलीज़ टीम ने थोड़ा धैर्य रखने का अनुरोध किया है

  • upload के बाद की follow-up कार्रवाई

    • source package uploader की ज़िम्मेदारी है कि संबंधित package का माइग्रेशन सुनिश्चित हो
    • अगर package reverse test dependencies में autopkgtest regression के कारण रुका है और उन dependencies के update की ज़रूरत है, तो uploader को उचित RC severity वाला bug दर्ज करना होगा

संबंधित पढ़ाई

2 टिप्पणियां

 
GN⁺ 2 시간 전
Hacker News टिप्पणियाँ

  • यह Debian और free software दुनिया के लिए एक बड़ी उपलब्धि है
    बस, इसकी ज़रूरत समझे जाने में काफ़ी समय लगा। 2007 में जब debian-devel पर कहा गया था कि इसकी ज़रूरत है, तब जवाब मिला था कि यह बहुत बड़ा समय की बर्बादी है, और सच में यहाँ तक पहुँचने के लिए बहुत लोगों की भारी मेहनत लगी, लेकिन यह पूरी तरह इसके लायक था

    • 2007 के बाद से Debian में ऐसा कोई बग या हमला नहीं हुआ जिसे reproducible packages रोक सकते थे
      मुझे नहीं लगता कि “इसके लायक था” कहना सही है। इससे सिर्फ Debian में योगदान देना और कठिन होता है, और मैंने पहले ही बहुत लोगों को Debian में योगदान की कठिनाई की शिकायत करते देखा है। पहले मैं यह कहकर बचाव करता था कि “packages को एक-दूसरे के साथ ठीक से काम कराने के लिए हर तरह की जाँच और नियंत्रण चाहिए”, लेकिन यह बिना ठोस वजह चीज़ों को मुश्किल बनाना लगता है और इसका लाभ भी सीमित दिखता है

  • https://wiki.debian.org/ReproducibleBuilds पर और जानकारी है। कुछ हिस्सा पुराना है, लेकिन वहाँ CI में build होने वाले packages की संख्या और उनमें कितने reproducible build हैं, यह दिखाने वाले charts भी हैं
    नारंगी रंग FTBR को दिखाता है, यानी “Fails To Build Reproducibly”। मैं charts से संख्या पढ़ने में बहुत अच्छा नहीं हूँ, लेकिन मोटे तौर पर यह कुछ प्रतिशत, शायद 4~5% लगता है

    • मुझे तो बस यह दिखता है:

      Forbidden

      You are not allowed to access this!
      HTML tags भी ज्यों के त्यों दिख रहे हैं :)
      संपादन: archive में “I Challenge Thee” पेज भी मिला। क्या यह किसी anti-bot measure से ब्लॉक हो रहा है? क्यों???

  • यह अच्छी बात है। NetBSD के पास 2017 से पूरी तरह reproducible builds हैं। https://blog.netbsd.org/tnf/entry/netbsd_fully_reproducible_...

    • जैसा लिंक में भी है, NetBSD ने यह Debian की मदद से हासिल किया। अगर मैं सही समझ रहा हूँ, तो यह NetBSD के ज़्यादा मेहनती होने से नहीं बल्कि समस्या के अपेक्षाकृत आसान होने से था। packages कम हैं और बदलाव भी कम होते हैं। वे अब भी CVS इस्तेमाल करते हैं, इसलिए “स्थिरता” कहना भी शायद कम होगा
      वैसे Debian के ज़्यादातर packages reproducible builds हैं। जो नहीं हैं, लगभग 5% के आसपास, उन्हें यहाँ graph में नारंगी रंग से दिखाया गया है: https://wiki.debian.org/ReproducibleBuilds
    • अगर थोड़ा शेखी बघारूँ, तो stagex ने पिछले साल पहली बार 100% full-source bootstrap पर आधारित deterministic और isolated builds हासिल किए, और हर release के लिए अलग-अलग maintainers द्वारा अपने-अपने hardware पर किए गए कई signed reproductions को अनिवार्य करने वाला भी पहला बना
      Debian ने भी बहुत प्रगति की है, लेकिन जब Debian कहता है कि वह reproducible है, तो उसका मतलब है कि वह अपने build के लिए third-party binaries लाता है। जब हम reproducible कहते हैं, तो हमारा मतलब है कि पूरे software supply chain के अंत तक 100% source code से bootstrap किया गया है
      मेरे हिसाब से यह फ़र्क महत्वपूर्ण है
      https://stagex.tools

  • इस बदलाव से सच में खुशी हुई। 2021 में SolarWinds attack के बारे में पढ़कर झटका लगा था, और उसी के बाद मैं reproducible builds में शामिल हुआ। [1]
    मुझे लगता है OpenJDK के reproducible builds पर काम करने वाले Magnus Ihse Bursie की बात सबसे उपयुक्त है: “अगर आप मुझसे पूछें, तो यह तथ्य कि compiler और build tools ने किसी समय से non-deterministic output बनाना शुरू कर दिया, अपने पहले दिन से ही bug था।” [2]
    [1] https://www.linux.com/news/preventing-supply-chain-attacks-l...
    [2] https://github.com/openjdk/jdk/pull/9152#issue-1270543997

  • सोच रहा हूँ कि आजकल यह मुद्दा क्यों बन रहा है। मैं embedded devices पर Yocto इस्तेमाल करता हूँ, और reproducible builds लगभग अपने-आप लागू किए जा सकते थे
    Debian package management भी आसानी से enable किया जा सकता है, इसलिए लगता है कि यह सब पहले से संभव था

    • “आजकल यह मुद्दा क्यों है” से आपका मतलब क्या है, यह जानना चाहूँगा
      reproducible builds industrial computing में एक ज़रूरी पद्धति है। Debian यहाँ किसी frontier पर नहीं है, बल्कि यह ज़्यादा इस तरह है कि वह पूरे industry में इस्तेमाल होने वाली उन तकनीकों को अपना रहा है जो long-term operation और safety-related use cases वाले दूसरे operating systems पर भी लागू होती हैं
      और हाँ, Yocto और Debian developers की बहुत सी कठिन मेहनत की वजह से अब हम इसका बहुत हिस्सा आसानी से इस्तेमाल कर पा रहे हैं
      दिलचस्प बात यह है कि अब Debian developers इसे और आगे बढ़ी हुई policy के रूप में लागू कर रहे हैं, ताकि यह विकल्प नहीं बल्कि default norm बन जाए
    • मैं यह जानना चाहता हूँ कि क्या उन्होंने सक्रिय रूप से verify किया है कि builds सच में bit-for-bit reproducible हैं

  • amd64 forky के आधार पर
    reproduced: 97.02%
    good: 17586
    bad: 511
    fail: 30
    unknown: 0
    ये आँकड़े, दूसरे architectures के आँकड़े, और reproducible न होने के कारण https://reproduce.debian.net पर देखे जा सकते हैं

  • मुझे हमेशा हैरानी होती है कि Debian यह आगे बढ़ा रहा है, commercial vendors नहीं। आप सोचेंगे कि RHEL और Ubuntu के लिए भुगतान करने वाले बड़े संगठन verifiable binaries की ज़ोरदार माँग करेंगे

    • अगर कोई competitor यह साबित कर सके कि उसका package किसी बड़े संगठन द्वारा वितरित package के bit-for-bit identical है, तो वह competitor उस बड़े संगठन की security assurance से लाभ उठा सकता है
      free software के लिए यह बहुत अच्छा है, लेकिन जो लोग monopoly चाहते हैं उनके लिए इतना अच्छा नहीं
    • reproducible builds की मौजूदगी trust की ज़रूरत कम करने के लिए है, लेकिन commercial vendors का काम ही trust बेचना है

  • Forbidden
    You don't have permission to access this resource.
    Apache Server at lists.debian.org Port 443
    :/

    • मुझे तो ठीक दिख रहा है। हो सकता है किसी ज़रूरत से ज़्यादा संवेदनशील firewall ने आपको bot समझ लिया हो
      वैसे भी यह Wayback Machine में है: https://web.archive.org/web/20260510074120/https://lists.deb...
 
GN⁺ 5 시간 전
Lobste.rs टिप्पणियाँ

  • सुरक्षा के नज़रिए से यह अच्छा बदलाव है। बदलाव की प्रक्रिया झंझट भरी हो सकती है, लेकिन अंततः यह दुनिया भर के Debian Linux उपयोगकर्ताओं को अधिक भरोसेमंद प्रणाली देगा

  • जिज्ञासा है कि Debian जैसे प्रोजेक्ट के लिए इसका मुख्य फ़ायदा क्या है। क्या मकसद यह है कि सबके पास बाइनरी में बैकडोर नहीं है, इसका प्रमाण हो?
    यानी क्या इससे मेंटेनरों पर आवश्यक भरोसा कम होता है और दुर्भावनापूर्ण मेंटेनर के जोखिम भी घटते हैं? मैं संदेह नहीं जता रहा, बस 100% समझ नहीं पाया कि Debian इस पर इतना समय क्यों लगा रहा है। बिल्ड को reproducible बनाना काफ़ी मुश्किल और मेहनत वाला काम लगता है

    • यह सिर्फ बैकडोर ही नहीं, बल्कि सामान्य छेड़छाड़ या संशोधन की भी जाँच संभव बनाता है। इससे सुरक्षा में मदद मिलती है और प्रोजेक्ट डेवलपमेंट में भी फ़ायदा होता है, क्योंकि reproducible और कुछ हद तक बंद वातावरण में बनने वाले पैकेज दूसरे डेवलपर वातावरण में अजीब तरह से टूटने की संभावना कम रखते हैं
      मूल बात यह है कि यह इस बात का प्रमाण देने वाले artifacts उपलब्ध कराता है कि आउटपुट पैकेज बनाने वाला source code वास्तव में वही specific source code है, कोई छिपा हुआ दूसरा source bundle नहीं। the reproducible-builds org has a bit of a 'why' which puts it better than i can
      reproducible builds बनाना बहुत कठिन है। उदाहरण के लिए compile pipeline के अंदर के timestamps भी फ़र्क डालते हैं, और generated archive का metadata भी। इन सबको हटाना पड़ता है, और कुछ मामलों में पैकेज खुद नहीं बल्कि CMake या Go compiler जैसे upstream projects के patches की ज़रूरत पड़ती है। कई मामलों में पहले इन समस्याओं को विचार में ही नहीं लिया जाता था, इसलिए पूरे build stack में काम करना पड़ता है। हालांकि यह काम काफ़ी समय से चल रहा है, इसलिए नींव का काफ़ी हिस्सा या तो पहले ही पूरा हो चुका है या गहराई से प्रगति पर है
    • मुझे नहीं लगता कि यह Debian की सबसे बड़ी प्राथमिकता होनी चाहिए, लेकिन Debian ऐसे काम नहीं करता। लोग वही काम करते हैं जो वे करना चाहते हैं, और व्यक्तियों की प्राथमिकताएँ अक्सर प्रोजेक्ट-स्तर की उचित प्राथमिकताओं से मेल नहीं खातीं

  • Debian जिस reproducibility की बात कर रहा है, क्या वह NixOS जैसी जगहों पर कहे जाने वाले विचार जैसा ही है?

    • नहीं। NixOS is not reproducible इस विषय पर मानक संदर्भ लेख है
    • जो distributions reproducible builds को एक प्रोजेक्ट की तरह ट्रैक करती हैं, वे आम तौर पर एक ही लक्ष्य की ओर बढ़ती हैं। reproducible-builds.org उन प्रोजेक्ट्स को ट्रैक करता है जो packaging pipeline में इस पर सक्रिय रूप से काम कर रहे हैं
      NixOS भी reproducible builds पर काम कर रहा है, और अगर मुझे सही याद है तो कम से कम ISO build और runtime दोनों में 100% reproducible है। लेकिन आम तौर पर NixOS के बारे में जिस reproducibility की बात होती है, वह यहाँ चर्चा किए जा रहे “reproducible builds” जैसी नहीं है। इस थ्रेड की sibling comment में लिंक किया गया foxboron का लेख देखें। वह environment reproducibility, या “deterministic build”, के ज़्यादा क़रीब है, और वह भी मूल्यवान है, लेकिन यहाँ उसी की बात नहीं हो रही

  • फ़िलहाल यह ratchet approach जैसा लग रहा है। क्या जो चीज़ें पहले कभी reproducible तरीके से build नहीं हुईं, वे अभी भी अनुमति प्राप्त हैं?

    • अगर कोई पैकेज reproducible तरीके से build नहीं होता, तो उसे अगले Debian release में शामिल नहीं किया जाएगा। यानी जो पैकेज “पहले कभी reproducible तरीके से build नहीं हुए” वे Debian unstable में रह सकते हैं, लेकिन जो पैकेज stable तक पहुँच ही नहीं सकते, उन्हें Debian unstable में बनाए रखना अच्छा नहीं माना जाता। हालांकि मेरी जानकारी में इसे यांत्रिक रूप से लागू करने वाला कोई नियम नहीं है