- यह दिखाया गया कि NixOS का minimal installation ISO, Hydra द्वारा वितरित बिल्ड के साथ bit-for-bit identical रूप में स्वतंत्र रूप से पुनर्निर्मित किया जा सकता है, जिससे यह सत्यापित किया जा सकता है कि वितरण बाइनरी और source आपस में मेल खाते हैं या नहीं
- इस बार के सत्यापन में ISO में शामिल पैकेजों के साथ-साथ ISO बनाने की प्रक्रिया स्वयं को भी पुनरुत्पादित किया गया, जिससे केवल पैकेज reproducibility से व्यापक दायरा जांचा गया
- पुनर्निर्माण NixOS 20.03 VirtualBox appliance से शुरू किया गया,
nixpkgsrevision63678e9f3d3aका उपयोग हुआ, और--option substitute falseके साथ binary cache पर निर्भरता बंद की गई - अगर 2020 OVA या डाउनलोड किया गया
gitकिसी परिष्कृत backdoor के साथ था, तो वह अब भी attack vector हो सकता है; इसलिए पूरी तरह bootstrapped system आधारित सत्यापन अभी बाकी है - minimal ISO का पुनर्निर्माण एक महत्वपूर्ण milestone है, लेकिन temporary workaround हटाना, अधिक installation media को reproducible बनाना, नियमित independent rebuild infrastructure, और build attestation tools अगले कार्य हैं
minimal ISO में सत्यापित reproducibility
- Hydra द्वारा प्रकाशित
nixos-minimalISO build को स्वतंत्र रूप से फिर से build किया गया और bit-for-bit identical output प्राप्त हुआ - reproducibility का दायरा दो हिस्सों में बंटा है
- ISO में जाने वाले सभी packages
- ISO बनाने वाली build process स्वयं
- ISO build के लिए आवश्यक लेकिन ISO के भीतर शामिल न होने वाले packages भी साथ में build किए गए, और cached binaries पर निर्भरता नहीं रखी गई
- reproducible builds एक trust path प्रदान करते हैं, जिससे यह जांचा जा सकता है कि distributed binaries source के प्रति faithful हैं या नहीं, और क्या Hydra जैसी build pipeline में उनके साथ छेड़छाड़ नहीं हुई
पुनर्निर्माण प्रक्रिया और सीमाएँ
- पुनर्निर्माण एक नए VirtualBox appliance में NixOS 20.03 से शुरू करके किया गया
- CPU और memory पर्याप्त मात्रा में allocate की गई, और disk को लगभग 65GB तक बढ़ाया गया
gitinstall करने के बादnixpkgsको clone किया गया और63678e9f3d3arevision checkout की गई--option substitute falseके साथ आवश्यक items को binary cache से लाने के बजाय local machine पर build किया गया
- प्रक्रिया में ज्ञात issues को bypass करने के लिए temporary measures शामिल थे
- supply-chain trust के दृष्टिकोण से कुछ सीमाएँ अब भी हैं
- अगर 2020 OVA या डाउनलोड किया गया
gitकिसी sophisticated backdoor के साथ था, तो वह अब भी attack vector हो सकता है - पूरी तरह bootstrapped system पर पुनर्निर्माण करना बेहतर होगा, लेकिन अभी उस चरण तक नहीं पहुँचा गया है
- संबंधित प्रगति nixpkgs supply-chain security project thread में जारी है
- अगर 2020 OVA या डाउनलोड किया गया
2021 की घोषणा और इस बार के नतीजे में अंतर
- 2021 में यह घोषणा हुई थी कि minimal ISO 100% reproducible है, लेकिन उस समय ISO build के लिए आवश्यक packages को केवल अलग-अलग reproduce किया गया था; वास्तविक ISO rebuild में अब भी अंतर बचा हुआ था
- इसका कारण Hydra cache और ISO निर्माण पद्धति से जुड़े शेष issues थे
- बाद में इन समस्याओं के ठीक होने के दौरान Python 3.10 की upstream समस्या जैसी regressions आईं, और इसी सप्ताह पूरी chain को सत्यापित करने की स्थिति वापस आई
- अगले चरणों में temporary workaround हटाना, अधिक packages को reproducible बनाना, और Gnome ISO जैसे अन्य installation media को reproduce करना शामिल है
- नियमित independent rebuild infrastructure और trustix जैसे build attestation को share और consume करने वाले tools की भी आवश्यकता है
1 टिप्पणियां
Hacker News की टिप्पणियां
source से minimal ISO को फिर से build करना, source-आधारित reproducible builds वाले system की यात्रा में एक प्रभावशाली milestone है
Guix ने भी हाल ही में इसी यात्रा में एक orthogonal लेकिन उतनी ही प्रभावशाली उपलब्धि हासिल की: बिना किसी दूसरे binary compiler blob के, सिर्फ एक reproducible 357-byte binary से पूरे compiler toolchain को bootstrap किया
शायद जल्द ही किसी दिन ये दोनों मिलकर पूरी distribution को source से reproducibly build कर सकें
https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-...
बहुत से लोग जो मुख्य बात नहीं समझते, वह यह है कि उद्देश्य यह साबित करना नहीं कि परिणाम 100% भरोसेमंद है, बल्कि यह साबित करना है कि परिणाम source के प्रति 100% faithful है
यानी अगर किसी गुप्त backdoor जैसी संदिग्ध चीज़ का पता चलता है, तो उसे हमेशा निर्णायक रूप से reproduce किया जा सकता है
खराब पक्ष के लिए इसका मतलब है कि भागने या छिपने की कोई जगह नहीं बचती
शायद पूरे 357 bytes की machine code को हाथ से document करके इंसानों के समझने लायक बनाया जा सकता है
मैंने कभी ऐसा काम नहीं किया, इसलिए सवाल मूर्खतापूर्ण हो सकता है, लेकिन सोचता हूं कि reproducibility default behavior क्यों नहीं है
अगर same source से software की दो copies compile की गईं, तो हर बार बिल्कुल identical होने से क्या रोकता है, यह मुझे साफ़ नहीं है
मुझे पता है कि moving parts बहुत हैं, लेकिन differences कैसे पैदा होते हैं, यह अब भी ठीक से समझ नहीं आता
आम समस्याओं की सूची यहां देख सकते हैं: https://reproducible-builds.org/docs/
कुल मिलाकर मुख्य बात यह है कि developers यह test नहीं करते कि build reproduce होता है या नहीं
अगर इसे release tests में शामिल कर दिया जाए, तो आमतौर पर वह लगातार reproducible बना रहता है
जानबूझकर non-reproducible बनाने वाले प्रमुख उदाहरणों में timestamps और author information शामिल हैं
ऐसी implicit जगहें भी हैं जो default reproducibility तोड़ देती हैं; उदाहरण के लिए कई runtimes hashmap item order define नहीं करते, और compiler उसी hashmap को iterate करके binary बना सकता है
कुछ operations order-independent नहीं हो सकते, और CPU state के आधार पर थोड़े अलग binaries निकल सकते हैं, जबकि सभी सही results हों
कभी समय या environment पर निर्भर metadata, thread execution order जैसी चीज़ें भी कारण बनती हैं
कम जानकारी के लिए माफ़ कीजिए, लेकिन मुझे लगा था कि NixOS के मौजूद होने की मुख्य वजहों में से एक reproducibility है
मुझे लगा था कि ये समस्याएं पहले ही solve हो चुकी होंगी
मैंने NixOS बस करीब 2 घंटे इस्तेमाल किया था और Hyprland आज़माना चाहता था; Hyprland में थोड़ी configuration चाहिए, इसलिए सोचा कि दूसरी distributions की तुलना में NixOS पर दूसरों की config उठाकर इस्तेमाल करना आसान होगा
लेकिन config ढूंढना भी मुश्किल था, random GitHub gist में करीब 3 मिलीं, पर कोई भी काम नहीं कर रही थी, इसलिए छोड़ दिया
यह सामान्य distributions की तरह पूरे system environment पर निर्भर नहीं करता, इसलिए कई मामलों में पहले से ही हर बार same binary निकलती है
लेकिन build process खुद कई packages में nondeterministic हो सकता है, इसलिए सिर्फ इससे तुरंत पूरी reproducibility नहीं मिलती
आप जिस मतलब के बारे में सोच रहे हैं, वह है binary package को आसानी से फिर build करने पर same dependency versions और build options वगैरह इस्तेमाल होना
यानी “मेरे laptop पर तो चला था” जैसी compilation errors के नए सिरे से पैदा होने की गुंजाइश नहीं होनी चाहिए
यहां जिस मतलब की बात हो रही है, वह है कि हर build artifact byte-for-byte identical binary बने
यह machine name, compile time, parallel build में file compilation खत्म होने के order आदि पर निर्भर नहीं होना चाहिए, और यह कहीं ज़्यादा कठिन है
अगर आप familiar नहीं हैं, तो “मुझे अभी तुरंत काम करने वाली चीज़ चाहिए” वाली स्थिति में यह चुनने लायक tool शायद ही हो
NixOS में “reproducible” का मतलब अधिकतर “same Nix code से same program behavior मिलता है” के करीब है
यह कुछ वैसा ही है जैसा लोग Dockerfile से उम्मीद करते हैं, और “मेरी machine पर तो चला” या “पिछली बार तो चला था” जैसी समस्याओं को solve करने के स्तर का है
इसके उलट “reproducible builds” का लक्ष्य है कि अलग-अलग machines पर बने artifacts bit-for-bit identical हों
इससे verify किया जा सकता है कि code किसी खास source set से build हुआ था, यानी security की एक अतिरिक्त layer मिलती है
config खोजते समय आपने कौन से search terms इस्तेमाल किए, यह भी जानना चाहूंगा
“nixos configuration” से search करने पर https://github.com/search?q=nixos%20configuration&type=repos... जैसे results मिलते हैं, और सिर्फ Hyprland देखें तो https://github.com/search?q=wayland.windowManager.hyprland&t... की तरह काफ़ी कुछ दिखता है
https://github.com/donovanglover/nix-config देखना अच्छा रहेगा
यह Flake-आधारित config है और इसमें Hyprland और कई अच्छी चीज़ें शामिल हैं
फिलहाल NixOS कमजोर लोगों या जिनके पास समय कम है, उनके लिए सही tool नहीं है
उम्मीद है कि किसी दिन यह बदलेगा, लेकिन अगर आप टिके रहें और उस दौर से निकल जाएँ तो फायदे मिल सकते हैं
सोच रहा हूँ कि क्या आपने GitHub code search इस्तेमाल किया था
संबंधित Home Manager options यहाँ मिल सकते हैं: https://mipmip.github.io/home-manager-option-search/?query=h...
फिर GitHub पर search कर सकते हैं: https://github.com/search?utf8=%E2%9C%93&q=lang%3Anix+hyprla...
कुछ options की खोज ज़्यादा casual या ज़्यादा advanced users की ओर इशारा कर सकती है
यह याद रखना चाहिए कि Nix / NixOS / Nixpkgs की reproducibility source की reproducibility है
source बदलने पर आपको warning मिलती है, लेकिन यह उस binary reproducibility से अलग है जिसमें binaries हर build पर अलग हो सकते हैं
Nix / NixOS / Nixpkgs की binary reproducibility कम-से-कम व्यवस्थित रूप से बहुत अच्छी तरह test नहीं की जाती
Guix, Arch Linux, Debian binary reproducibility को Nix / NixOS / Nixpkgs से बेहतर handle करते हैं
संदर्भ: https://r13y.com/ (Nix*) / https://tests.reproducible-builds.org/debian/reproducible.ht... (Debian) / https://tests.reproducible-builds.org/archlinux/archlinux.ht... (Arch Linux) / https://data.guix.gnu.org/repository/1/branch/master/latest-... (Guix, loading धीमी हो सकती है और cached copy https://archive.is/lTuPk है)
input reproducibility का मतलब “inputs के लिए perfect cache invalidation” है
Nix और Guix इसे design से पूरी तरह करते हैं, और कभी-कभी ज़रूरत से ज़्यादा rebuilds भी करा देते हैं
Debian और Arch Linux इसे primary concern नहीं मानते, और किसी खास source file के update होने पर कौन-से packages फिर से build करने हैं, इस समस्या को manual rebuild triggers जैसे ad-hoc तरीकों से संभालते हैं
output reproducibility का मतलब “build process deterministic है और हमेशा वही binary बनाता है” है, और यही मूल लेख का विषय है
Nix packages को sandbox में build करता है, इसलिए मदद मिलती है, लेकिन यह कोई silver bullet नहीं है
इस मामले में Nix भी Debian, Arch Linux जैसी ही नाव में है
असल में distributions reproducibility बढ़ाने वाले patches अक्सर upstream को भेजते हैं, और दूसरे distributions भी उसका फायदा उठाते हैं
इस context में https://reproducible.nixos.org बाकी दिए गए links का counterpart है, और मैं मानता हूँ कि Nix report कम detailed है, लेकिन इसका मतलब यह नहीं कि Nix की binary reproducibility और खराब है
अगर इसे “Nix सिर्फ़ input reproducibility में अच्छा है और binary reproducibility में अच्छा नहीं है” की तरह पढ़ा जाए, तो यह गलत होगा
यहाँ उसी milestone का जश्न मनाया जा रहा है
यह लेख सिर्फ़ binaries ही नहीं, बल्कि उन्हें ISO में package करने के तरीके को भी bit-for-bit reproduce करने की बात है
r13y.com पुराना हो चुका है, और याद है कि missing 1% से भी कम हिस्सा भी upstream Python regression की वजह से था
binaries की अपनी reproducibility, ISO packaging को छोड़कर, कई साल पहले ही हासिल हो चुकी थी
core ISO से आगे packages पर जाएँ तो comparison जटिल हो जाता है
packages को handle करने का तरीका subtle लेकिन इस context में महत्वपूर्ण रूप से अलग है, और Arch के AUR में मिलने वाले कई packages Nix में normal packages के रूप में हैं, साथ ही अधिकांश -bin upstream packages भी Nix में सचमुच ज़रूरी नहीं होते
आम तौर पर Nix reproducible builds बनाना आसान करता है, लेकिन Nix से अलग यह हमेशा संभव नहीं होता और अक्सर patches की ज़रूरत पड़ती है
जब Nix के default package repository में 80,000 से ज़्यादा packages हैं, जबकि Arch में AUR को छोड़कर 15,000 से कम हैं, तो percentage comparison बहुत उपयोगी नहीं रह जाता
एक बहुत आम गलतफहमी यह है कि लोग सोचते हैं Nix store path का hash build output पर आधारित होता है, जबकि असल में वह isolated environment में binary build करने के लिए इस्तेमाल किए गए सभी sources और inputs के पूरे set पर आधारित होता है, चाहे वे binary हों या नहीं
इसलिए लोगों द्वारा अपेक्षित security benefits वैसे ही नहीं मिलते, लेकिन इसके बजाय यह ऐसी software को भी, जो reproducibly build नहीं होती, features, compiler settings, dependency versions, user, configuration आदि समान रखते हुए reasonably reproducible distribution form में इस्तेमाल करने देता है
यह देखने की बात है कि same source से अलग-अलग machines पर build करने पर binary वही रहती है या नहीं
मुद्दा यह है कि binary हर build पर बदलती नहीं है
testing method में भी लिखा है कि हर build को अलग-अलग समय, अलग hardware, अलग kernel पर दो बार run किया जाता है
देखने पर यह 85.6% reproducible दिखाता है: https://reproducible.archlinux.org
NixOS में, जहाँ official repository में 80,000 से ज़्यादा packages हैं, इसके लिए कितना काम लगेगा, यह सोचने वाली बात है
nixpkgs के लक्ष्य या वास्तविकता को देखते हुए यह बिल्कुल सच नहीं है
मूल लेख कई binary packages वाले binary minimal ISO को reproduce करने की बात करता है
यह बात ironic है और हंसी आती है कि OpenBSD project पूरी तरह उल्टी दिशा में जोर-शोर से जा रहा है
OpenBSD में हर installation के लिए unique और randomized address offset होता है
मैं समझता हूं कि reproducible builds और unique installation ये दो लक्ष्य एक-दूसरे से orthogonal हैं और साथ-साथ हासिल किए जा सकते हैं, लेकिन यह duality फिर भी मजेदार लगती है
या program start होते समय offset को randomize करने का तरीका भी reproducibility बनाए रखते हुए security को और बढ़ा सकता है
तब हर run पर offset बदल जाएगा
package खुद फिर भी reproducible हो सकते हैं
सारी randomization package download करने और checksum verify करने के बाद local मशीन पर की जाती है
अब अच्छा होगा अगर maintainer package पर सिर्फ sign कर दें, जैसा कि लगभग बाकी सभी Linux distributions 90s से करते आए हैं
ताकि सभी को कुछ हद तक पता रहे कि वे जो code build कर रहे हैं वह वही code है जिसे जाने-माने व्यक्तियों ने submit और review किया है
signatures standardize होने से पहले, किसी valuable चीज़ को protect करने वाले production use में Nix का इस्तेमाल करना कल्पना करना मुश्किल है
अधिकतर package contents के बारे में कोई guarantee नहीं देते
उनके signature से meaningful assurances की उम्मीद करना कुछ ऐसा लगता है जैसे delivery driver से product support की उम्मीद करना
यह भरोसा करने की भी जरूरत नहीं कि package malicious तरीके से नहीं बनाया गया
Nix reproducible builds करता है, इसलिए अगर आप binary cache पर निर्भर नहीं रहना चाहते, तो derivation देखकर खुद build कर सकते हैं
मूल content malicious है या नहीं, यह आखिरकार developer और user के बीच का मामला है
अगर दूसरी distributions ने लोगों को उल्टा मानने पर मजबूर किया है, तो मेरे हिसाब से वह misleading के करीब है
दिमाग में आने वाला exception बस Tails है, लेकिन Tails Nix जितना व्यापक नहीं है
देखने में लगता है कि Debian अब ऐसा नहीं करता और build system build पर sign करता है, Fedora भी नहीं करता, और Arch को लेकर पक्का नहीं हूं लेकिन लगता है वह भी नहीं करता
NixOS build system सभी build artifacts को अपनी key से sign करता है और download के समय signature verify करता है
अगर paranoid approach लें, तो Nix कम-से-कम हर चीज़ को source से खुद build करना आसान बना देता है
यह बहुत impressive milestone है, और जिन लोगों ने इसे संभव बनाया उन्हें बधाई
ISO को वास्तव में फिर से build करते समय भी differences आए थे, और बताया गया है कि वजह Hydra cache में बचे हुए issues और ISO generation का तरीका था
क्या कोई समझा सकता है कि “ISO जिस तरीके से generate हुआ था” उसे कैसे fix किया गया?
पहले मैंने reproducible ISO बनाने की कोशिश की थी, लेकिन file system को extent deterministically तय करवाने में सफल नहीं हो पाया
उस process का आखिरी step
./result/isodirectory में ISO बनाता हैलगता है आप उस build द्वारा call किए गए command को ढूंढ रहे हैं, लेकिन मुझे पक्का नहीं कि आप कौन-सा step ढूंढ रहे हैं
उदाहरण के लिए
xorrisocall यहां है: https://github.com/NixOS/nixpkgs/blob/master/nixos/lib/make-...ऐसा करने के लिए system time को spoof करना नहीं पड़ेगा?
time अक्सर किसी न किसी तरह binaries के अंदर चला जाता है
यह इतना common है कि कई compilers ने timestamps spoof करने के लिए de facto standard variable SOURCE_DATE_EPOCH implement किया है: https://reproducible-builds.org/docs/source-date-epoch/
क्या यह Ken Thompson द्वारा “Reflections on Trusting Trust” में लिखी समस्या को हल करने में मदद नहीं करता?
अगर पूरे system को source code से पूरी तरह bootstrap किया जा सके, तो backdoored compiler जैसी चीज़ डालना ज्यादा मुश्किल लगता है
theoretically ISO जिस environment में build होता है, उसके अंदर कोई sophisticated backdoor हो सकता है
अगर उस समस्या को सच में हल करना है, तो Diverse Double Compiling(https://dwheeler.com/trusting-trust/) या पूरे environment bootstrapping(https://bootstrappable.org/) देखें
लेख का “क्या ऊपर के approach में bootstrap problem नहीं है?” section भी related है
फिर भी सिर्फ build reproduce करना भी ऐसे attacks की संभावना को लगातार कम करने में काफी मदद करता है
हाल के काम की वजह से मैं Red Hat ecosystem में रहा हूं
जिज्ञासा है कि यह Fedora Silverblue, Ansible, Fedora Silverblue + Ansible जैसी चीज़ों की तुलना में कैसा है
Imagebuilder reproducibility का दावा करता है, लेकिन जहां तक मुझे पता है, यह ज्यादातर rpm packages को source के बजाय binaries के रूप में install करता है
इसलिए अगर सभी input packages भी reproducible नहीं हैं, तो strict reproducibility नहीं है
अगर source से packages build करने, distribution image बनाने और reproducibility पर बात आपको ठीक से relate नहीं हुई, तो शायद आप इसका main target audience नहीं हैं
वहीं Ansible OS द्वारा follow किए जाने वाले steps specify करता है
Silverblue और Nix, Linux distribution होने के अलावा, एक-दूसरे से काफ़ी अलग अवधारणाएँ हैं
Silverblue, immutable host के ऊपर सिर्फ़ containers का उपयोग करके software delivery का तरीका बदलने की कोशिश है
अगर आप Jsonnet और state tracking का उपयोग करके Nix की कुछ हद तक नकल करने वाला Ansible alternative खोज रहे हैं, तो Etcha देखने लायक है: https://etcha.dev
Nix immutable है
नए बदलाव पूरी तरह नए सिरे से बनाए जाते हैं, और build सफल होने के बाद ही सभी packages मौजूदा system में “symbolic link” किए जाते हैं
Fedora Silverblue ostree-based है https://github.com/ostreedev/ostree
यह root tree के लिए git जैसा काम करता है, लेकिन changes लागू करने के लिए पूरे system को reboot करना पड़ता है
Nix packages को symbolic link करने के तरीके पर आधारित है, इसलिए system को reboot करने की ज़रूरत नहीं होती
ज़्यादा विस्तृत explanation यहाँ है: https://dataswamp.org/~solene/2023-07-12-intro-to-immutable-...