NixOS การบิลด์ที่ทำซ้ำได้: สร้าง ISO ติดตั้งขั้นต่ำแบบอิสระสำเร็จ
(discourse.nixos.org)- ISO ติดตั้งขั้นต่ำของ NixOS สามารถถูกสร้างซ้ำแบบอิสระให้ เหมือนกับฉบับที่ Hydra แจกจ่ายในระดับบิตต่อบิต ได้ แสดงให้เห็นว่าสามารถตรวจสอบความสอดคล้องกันระหว่างไบนารีที่เผยแพร่กับซอร์สได้
- การตรวจสอบครั้งนี้ไม่ได้ครอบคลุมแค่แพ็กเกจที่อยู่ใน ISO เท่านั้น แต่ยังครอบคลุมถึง กระบวนการสร้าง ISO เอง ด้วย จึงยืนยันขอบเขตที่กว้างกว่าการทำซ้ำแพ็กเกจเพียงอย่างเดียว
- การสร้างซ้ำเริ่มจาก NixOS 20.03 VirtualBox appliance ใช้
nixpkgsrevision63678e9f3d3aและปิด การพึ่งพา binary cache ด้วย--option substitute false - หาก OVA ปี 2020 หรือ
gitที่ดาวน์โหลดมามีแบ็กดอร์ที่ซับซ้อน ก็ยังอาจเป็นช่องทางโจมตีได้ ดังนั้นการตรวจสอบบนระบบที่ bootstrapped อย่างสมบูรณ์ ยังเป็นสิ่งที่ต้องทำต่อไป - การสร้างซ้ำ minimal ISO ถือเป็นหมุดหมายสำคัญ แต่โจทย์ถัดไปคือการถอดวิธีเลี่ยงชั่วคราว การทำซ้ำ installation media เพิ่มเติม โครงสร้างพื้นฐานสำหรับการสร้างซ้ำแบบอิสระเป็นประจำ และเครื่องมือ หลักฐานการบิลด์
ความสามารถในการทำซ้ำที่ยืนยันแล้วบน minimal ISO
- สร้าง
nixos-minimalISO build ที่ Hydra เผยแพร่ขึ้นมาใหม่แบบอิสระ และได้ผลลัพธ์ที่ เหมือนกันทุกบิต - ขอบเขตของการทำซ้ำแบ่งออกเป็นสองแกน
- ทุกแพ็กเกจ ที่อยู่ใน ISO
- กระบวนการบิลด์เอง ที่ใช้สร้าง ISO
- มีการบิลด์แพ็กเกจที่จำเป็นต่อการบิลด์ ISO แต่ไม่ได้รวมอยู่ใน ISO ไปพร้อมกันด้วย และไม่พึ่งพาไบนารีที่แคชไว้
- การบิลด์ที่ทำซ้ำได้ช่วยสร้างเส้นทางความเชื่อมั่นสำหรับตรวจสอบว่าไบนารีที่แจกจ่ายมาสอดคล้องกับซอร์ส และไม่ได้ถูกแก้ไขระหว่างทางใน build pipeline อย่าง Hydra
ขั้นตอนการสร้างซ้ำและข้อจำกัด
- การสร้างซ้ำทำโดยเริ่มจาก NixOS 20.03 บน VirtualBox appliance ใหม่
- จัดสรร CPU และหน่วยความจำให้เพียงพอ และขยายดิสก์เป็นราว 65GB
- ติดตั้ง
gitแล้วโคลนnixpkgsและ checkout revision63678e9f3d3a - ใช้
--option substitute falseเพื่อไม่ดึงรายการที่จำเป็นจาก binary cache แต่บิลด์บนเครื่องภายในแทน
- ขั้นตอนนี้มีมาตรการชั่วคราวเพื่อเลี่ยงปัญหาที่ทราบอยู่
- ยังมีข้อจำกัดในด้านความน่าเชื่อถือของซัพพลายเชน
- หาก OVA ปี 2020 หรือ
gitที่ดาวน์โหลดมามีแบ็กดอร์ที่ซับซ้อน ก็ยังอาจเป็นช่องทางโจมตีได้ - การสร้างซ้ำบนระบบที่ bootstrapped อย่างสมบูรณ์จะดีกว่า แต่ยังไปไม่ถึงขั้นนั้น
- ความคืบหน้าที่เกี่ยวข้องยังดำเนินต่อใน เธรด nixpkgs supply-chain security project
- หาก OVA ปี 2020 หรือ
ความต่างระหว่างประกาศปี 2021 กับผลลัพธ์ครั้งนี้
- ในปี 2021 เคยมี ประกาศ ว่า minimal ISO ทำซ้ำได้ 100% แต่ในเวลานั้นเป็นเพียงการทำซ้ำแพ็กเกจที่จำเป็นต่อการบิลด์ ISO ทีละรายการ และยังมีความต่างอยู่ในการสร้าง ISO จริง
- สาเหตุมาจาก ปัญหาที่ยังค้างอยู่ ใน Hydra cache และวิธีการสร้าง ISO
- หลังจากแก้ปัญหาเหล่านั้น ก็เกิด regression ตามมาบ้าง เช่นปัญหา upstream ของ Python 3.10 และเพิ่งกลับมาสู่จุดที่ตรวจสอบทั้งเชนได้อีกครั้งในสัปดาห์นี้
- ขั้นต่อไปคือการถอดวิธีเลี่ยงชั่วคราว การทำซ้ำแพ็กเกจเพิ่มขึ้น และการทำซ้ำ installation media อื่น ๆ เช่น Gnome ISO
- ยังต้องมีโครงสร้างพื้นฐานสำหรับการสร้างซ้ำแบบอิสระเป็นประจำ และเครื่องมือสำหรับแชร์และใช้งานหลักฐานการบิลด์ เช่น trustix
1 ความคิดเห็น
ความคิดเห็นใน Hacker News
การที่สามารถสร้าง ISO ขั้นต่ำ ขึ้นใหม่จากซอร์สได้ ถือเป็นหมุดหมายที่น่าประทับใจบนเส้นทางสู่ระบบที่บิลด์ซ้ำได้จากซอร์ส
เมื่อไม่นานมานี้ Guix ก็ทำสำเร็จในเส้นทางเดียวกันในลักษณะที่ตั้งฉากกันแต่ก็น่าประทับใจไม่แพ้กัน โดยบูตสแตรปทั้ง toolchain ของคอมไพเลอร์จาก ไบนารี 357 ไบต์ ที่ทำซ้ำได้เพียงตัวเดียว โดยไม่มี binary compiler blob อื่น ๆ
สักวันในเร็ว ๆ นี้ ทั้งสองอย่างนี้อาจถูกรวมเข้าด้วยกัน จนสามารถบิลด์ดิสโทรทั้งชุดจากซอร์สแบบทำซ้ำได้
https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-...
ประเด็นสำคัญที่หลายคนไม่เข้าใจคือ ไม่ใช่การพิสูจน์ว่าผลลัพธ์เชื่อถือได้ 100% แต่เป็นการพิสูจน์ว่าผลลัพธ์ ตรงกับซอร์ส 100%
กล่าวคือ หากพบพฤติกรรมน่าสงสัยอย่างแบ็กดอร์ลับ ๆ ก็จะสามารถทำซ้ำมันได้อย่างเด็ดขาดเสมอ
ฝ่ายไม่หวังดีก็เท่ากับไม่มีที่ให้หนีหรือซ่อนอีกต่อไป
น่าจะทำเอกสารโค้ดเครื่องทั้ง 357 ไบต์ด้วยมือให้คนอ่านเข้าใจได้ด้วยซ้ำ
อาจเป็นคำถามโง่ ๆ เพราะไม่เคยทำเรื่องแบบนี้มาก่อน แต่สงสัยว่าทำไม การทำซ้ำได้ ถึงไม่ใช่พฤติกรรมปริยาย
ถ้าคอมไพล์ซอฟต์แวร์สองชุดจากซอร์สเดียวกัน ก็ไม่ค่อยเข้าใจว่าอะไรเป็นตัวขัดขวางไม่ให้มันเหมือนกันทุกประการทุกครั้ง
รู้ว่ามีชิ้นส่วนที่เคลื่อนไหวเยอะ แต่ก็ยังไม่เข้าใจดีนักว่าความแตกต่างเกิดขึ้นได้อย่างไร
ดูรายการปัญหาทั่วไปได้ที่นี่: https://reproducible-builds.org/docs/
โดยรวมแล้ว ประเด็นหลักคือผู้พัฒนาไม่ได้ทดสอบว่ามันทำซ้ำได้หรือไม่
ถ้ารวมไว้ในการทดสอบรีลีส ก็มักจะรักษาสถานะที่ทำซ้ำได้ต่อไปได้
ตัวอย่างชัด ๆ ที่ทำให้ทำซ้ำไม่ได้ ได้แก่ timestamp และข้อมูลผู้เขียน
ยังมีจุดที่ทำลายความสามารถในการทำซ้ำโดยปริยายแบบไม่รู้ตัวด้วย เช่น runtime จำนวนมากไม่ได้กำหนดลำดับของรายการใน hashmap และคอมไพเลอร์อาจวนผ่าน hashmap นั้นเพื่อสร้างไบนารี
อาจมีงานที่ลำดับมีผล และขึ้นอยู่กับสถานะของ CPU แล้วไบนารีที่ได้อาจต่างกันเล็กน้อย แต่ทั้งหมดก็ยังเป็นผลลัพธ์ที่ถูกต้อง
บางครั้งก็เกิดจากเมทาดาทาที่ขึ้นกับเวลา หรือสภาพแวดล้อม รวมถึงลำดับการทำงานของเธรด
ขอโทษที่ไม่ค่อยรู้เรื่อง แต่คิดว่าเหตุผลหลักข้อหนึ่งที่ NixOS มีอยู่ก็คือ การทำซ้ำได้
นึกว่าปัญหาเหล่านี้ถูกแก้ไปแล้ว
ผมเคยใช้ NixOS แค่ประมาณ 2 ชั่วโมง และอยากลอง Hyprland ซึ่งต้องตั้งค่าพอสมควร เลยคิดว่าการเอาคอนฟิกของคนอื่นมาใช้บน NixOS น่าจะง่ายกว่าดิสโทรอื่น
แต่หาคอนฟิกก็ยาก และแม้จะเจอราว 3 อันจาก GitHub gist แบบสุ่ม ๆ ก็ไม่มีอันไหนทำงานได้ เลยยอมแพ้
มันไม่ได้พึ่งพาสภาพแวดล้อมทั้งระบบเหมือนดิสโทรทั่วไป ดังนั้นในหลายกรณีก็ได้ไบนารีเดิมทุกครั้งอยู่แล้ว
แต่กระบวนการบิลด์เองยังอาจไม่เป็น deterministic ในหลายแพ็กเกจ ดังนั้นแค่นี้จึงยังไม่ได้ทำให้ทำซ้ำได้อย่างสมบูรณ์ในทันที
ความหมายที่คุณคิดถึงคือ การบิลด์แพ็กเกจไบนารีขึ้นใหม่ได้ง่าย ๆ โดยใช้เวอร์ชัน dependency และตัวเลือกการบิลด์ชุดเดิม ฯลฯ
หมายถึงไม่ควรมีช่องให้เกิดข้อผิดพลาดตอนคอมไพล์แบบ “บนแล็ปท็อปผมใช้ได้นะ” ขึ้นมาใหม่
ส่วนความหมายที่พูดถึงที่นี่คือผลลัพธ์จากการบิลด์ทั้งหมดต้องเป็น ไบนารีที่เหมือนกันในระดับไบต์
ต้องไม่ขึ้นกับชื่อเครื่อง เวลาที่คอมไพล์ หรือลำดับที่การคอมไพล์ไฟล์เสร็จในการบิลด์แบบขนาน และแบบนี้ยากกว่ามาก
ถ้ายังไม่คุ้นเคย มันแทบไม่ใช่เครื่องมือที่จะเลือกในสถานการณ์แบบ “อยากได้อะไรที่ใช้ได้ตอนนี้เลย”
คำว่า “ทำซ้ำได้” ใน NixOS ใกล้เคียงกับความหมายว่า “ใช้โค้ด Nix เดิมแล้วได้พฤติกรรมของโปรแกรมแบบเดิม”
คล้ายกับสิ่งที่ผู้คนคาดหวังจาก Dockerfile และอยู่ในระดับที่พยายามแก้ปัญหา “บนเครื่องผมใช้ได้” หรือ “ครั้งที่แล้วใช้ได้”
ในทางกลับกัน “reproducible builds” ตั้งเป้าให้ artefact ที่สร้างบนคนละเครื่อง เหมือนกันในระดับบิต
แบบนี้ทำให้ตรวจสอบได้ว่าโค้ดถูกบิลด์จากชุดซอร์สที่กำหนดจริงหรือไม่ จึงเพิ่มชั้นความปลอดภัยขึ้นมาอีกชั้น
อยากรู้เหมือนกันว่าตอนหาคอนฟิก คุณใช้คำค้นหาอะไร
ถ้าค้นว่า “nixos configuration” ก็จะเจอผลลัพธ์อย่าง https://github.com/search?q=nixos%20configuration&type=repos... และถ้าดูเฉพาะ Hyprland ก็เห็นว่ามีค่อนข้างเยอะ เช่น https://github.com/search?q=wayland.windowManager.hyprland&t...
ลองดู https://github.com/donovanglover/nix-config ก็น่าจะดี
เป็นการตั้งค่าบนฐาน Flake และมี Hyprland กับของดี ๆ หลายอย่างรวมอยู่
ตอนนี้ NixOS ยังไม่ใช่เครื่องมือที่เหมาะกับคนใจไม่แข็งหรือคนที่มีเวลาไม่มาก
หวังว่าสักวันจะเปลี่ยนไป แต่ถ้าอดทนผ่านไปได้ก็จะได้ประโยชน์จากมัน
สงสัยว่าได้ใช้การค้นหาโค้ดของ GitHub หรือเปล่า
ตัวเลือก Home Manager ที่เกี่ยวข้องหาได้ที่นี่: https://mipmip.github.io/home-manager-option-search/?query=h...
จากนั้นค่อยค้นหาใน GitHub ได้: https://github.com/search?utf8=%E2%9C%93&q=lang%3Anix+hyprla...
การค้นหาตัวเลือกบางอย่างอาจสื่อไปทางผู้ใช้ทั่วไปมากกว่า หรือผู้ใช้ขั้นสูงมากกว่า
ต้องจำไว้ว่าความสามารถในการทำซ้ำของ Nix / NixOS / Nixpkgs คือ ความสามารถในการทำซ้ำของซอร์ส
ถ้าซอร์สเปลี่ยนก็จะมีคำเตือน แต่มันต่างจากความสามารถในการทำซ้ำของไบนารีที่อาจเปลี่ยนไปได้ทุกครั้งที่ build
ความสามารถในการทำซ้ำของไบนารีใน Nix / NixOS / Nixpkgs อย่างน้อยในเชิงระบบแล้วถือว่ายังไม่ได้ถูกทดสอบดีนัก
Guix, Arch Linux และ Debian จัดการเรื่องความสามารถในการทำซ้ำของไบนารีได้ดีกว่า Nix / NixOS / Nixpkgs
แหล่งข้อมูล: 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, อาจโหลดช้า และมีสำเนาแคชที่ https://archive.is/lTuPk)
ความสามารถในการทำซ้ำของอินพุต หมายถึง “การทำให้แคชหมดอายุอย่างสมบูรณ์ตามอินพุต”
Nix และ Guix ทำสิ่งนี้ได้สมบูรณ์ตามการออกแบบ และบางครั้งก็ทำให้ต้อง rebuild มากเกินไปด้วย
Debian และ Arch Linux ไม่ได้ถือเรื่องนี้เป็นประเด็นหลัก และจัดการปัญหาว่าเมื่อไฟล์ซอร์สบางไฟล์อัปเดตแล้วควร build แพ็กเกจใดใหม่ ด้วยวิธีเฉพาะหน้าอย่าง trigger การ rebuild แบบแมนนวล
ความสามารถในการทำซ้ำของเอาต์พุต หมายถึง “กระบวนการ build เป็นแบบกำหนดผลลัพธ์แน่นอนและสร้างไบนารีเดิมเสมอ” ซึ่งเป็นหัวข้อของบทความต้นทาง
Nix ช่วยได้เพราะ build แพ็กเกจใน sandbox แต่ไม่ใช่วิธีแก้สารพัดปัญหา
ในแง่นี้ Nix ก็อยู่เรือลำเดียวกับ Debian และ Arch Linux
จริง ๆ แล้วดิสโทรต่าง ๆ มักส่งแพตช์ที่เพิ่ม reproducibility กลับไปยัง upstream และดิสโทรอื่น ๆ ก็ได้ประโยชน์ตามไปด้วย
ในบริบทนี้ https://reproducible.nixos.org คือคู่เทียบของลิงก์อื่น ๆ ที่ยกมา และผมเห็นด้วยว่ารายงานของ Nix มีรายละเอียดน้อยกว่า แต่นั่นไม่ได้แปลว่าความสามารถในการทำซ้ำของไบนารีของ Nix แย่กว่า
ถ้าอ่านเป็นว่า “Nix ทำได้ดีแค่ความสามารถในการทำซ้ำของอินพุต แต่ทำความสามารถในการทำซ้ำของไบนารีได้ไม่ดี” ก็เป็นความเข้าใจที่ผิด
หมุดหมายที่กำลังฉลองกันอยู่ตรงนี้ก็คือเรื่องนั้นพอดี
บทความนี้พูดถึงการทำซ้ำแบบตรงกันระดับบิต ไม่ใช่แค่ไบนารี แต่รวมถึง วิธีที่ไบนารีเหล่านั้นถูกแพ็กเป็น ISO ด้วย
r13y.com อยู่ในสภาพล้าสมัยแล้ว และส่วนที่ขาดไปไม่ถึง 1% ถ้าจำไม่ผิดก็เป็นเพราะ regression จาก upstream Python
ความสามารถในการทำซ้ำของตัวไบนารีเอง ถ้าไม่นับการแพ็กเป็น ISO ก็ทำสำเร็จไปตั้งแต่หลายปีก่อนแล้ว
พอไปถึงแพ็กเกจที่อยู่นอกเหนือ ISO หลัก การเปรียบเทียบจะซับซ้อนขึ้น
วิธีจัดการแพ็กเกจมีความแตกต่างที่ละเอียดอ่อนแต่สำคัญในบริบทนี้ และแพ็กเกจจำนวนมากที่น่าจะอยู่ใน AUR ของ Arch นั้นใน Nix ถูกนับเป็นแพ็กเกจปกติ อีกทั้งแพ็กเกจ upstream แบบ -bin ส่วนใหญ่ก็ไม่จำเป็นใน Nix
โดยทั่วไป Nix ทำให้การสร้าง build ที่ทำซ้ำได้ง่ายขึ้น แต่ไม่ได้แปลว่าเป็นไปได้เสมอโดยไม่เกี่ยวกับ Nix และบ่อยครั้งก็ต้องมีแพตช์
เมื่อรวมกับข้อเท็จจริงที่ว่า repository แพ็กเกจหลักของ Nix มีมากกว่า 80,000 แพ็กเกจ ขณะที่ Arch มีน้อยกว่า 15,000 แพ็กเกจหากไม่นับ AUR การเปรียบเทียบเป็นเปอร์เซ็นต์จึงไม่ค่อยมีประโยชน์
ความเข้าใจผิดที่พบบ่อยมากอย่างหนึ่งคือคิดว่า hash ของ path ใน Nix store อิงจากผลลัพธ์ของ build แต่จริง ๆ แล้วมันอิงจากซอร์สและอินพุตทั้งหมดที่ใช้สร้างไบนารีในสภาพแวดล้อมที่ถูกแยก ไม่ว่าจะเป็นไบนารีหรือไม่ก็ตาม
ดังนั้นมันจึงไม่ได้ให้ประโยชน์ด้านความปลอดภัยตามที่หลายคนคาดหวังไว้โดยตรง แต่ในทางกลับกัน มันทำให้ซอฟต์แวร์ที่ไม่ได้ build แบบทำซ้ำได้ ยังสามารถถูกใช้งานในรูปแบบการจัดส่งที่ทำซ้ำได้อย่างสมเหตุสมผล โดยมีฟีเจอร์ การตั้งค่าคอมไพเลอร์ เวอร์ชัน dependency ผู้ใช้ และ configuration เหมือนกัน
คือการตรวจสอบว่าเมื่อ build จากซอร์สเดียวกันบนเครื่องต่างกัน ไบนารีออกมาเหมือนกันหรือไม่
ประเด็นคือไบนารีไม่ได้เปลี่ยนไปทุกครั้งที่ build
วิธีทดสอบก็บอกไว้ว่ารันการ build แต่ละครั้งสองรอบ โดยต่างเวลา ต่างฮาร์ดแวร์ และต่าง kernel กัน
ดูแล้วระบุว่า ทำซ้ำได้ 85.6%: https://reproducible.archlinux.org
อยากรู้เหมือนกันว่าจะต้องใช้แรงงานมากแค่ไหนสำหรับ NixOS ที่มีแพ็กเกจใน repository ทางการมากกว่า 80,000 แพ็กเกจ
เมื่อดูจากเป้าหมายหรือความเป็นจริงของ nixpkgs แล้ว ไม่ใช่ข้อเท็จจริงเลย
บทความต้นฉบับพูดถึงการทำให้ ISO ขั้นต่ำแบบไบนารี ซึ่งมีแพ็กเกจไบนารีหลายตัวอยู่ภายใน สามารถสร้างซ้ำได้
น่าขำในเชิงประชดที่โปรเจกต์ OpenBSD กำลังมุ่งไปอย่างจริงจังในทิศทางตรงกันข้ามพอดี
OpenBSD มีออฟเซ็ตที่อยู่ที่ไม่ซ้ำกันและถูกสุ่มสำหรับการติดตั้งทุกครั้ง
เข้าใจได้ว่าเป้าหมายสองอย่างคือ build ที่ทำซ้ำได้กับการติดตั้งที่เป็นเอกลักษณ์นั้นตั้งฉากกันและทำให้สำเร็จพร้อมกันได้ แต่ความเป็นสองด้านนี้ก็ยังน่าขำอยู่ดี
หรือจะใช้วิธีสุ่มออฟเซ็ตตอนเริ่มโปรแกรมก็ได้ ซึ่งช่วยเพิ่มความปลอดภัยโดยยังคงความสามารถในการทำซ้ำไว้
แบบนั้นออฟเซ็ตจะเปลี่ยนทุกครั้งที่รัน
ตัวแพ็กเกจเองยังคงทำซ้ำได้
การสุ่มทั้งหมดทำในเครื่องหลังจากดาวน์โหลดแพ็กเกจและตรวจสอบ checksum แล้ว
ตอนนี้ก็อยากให้ผู้ดูแลแพ็กเกจแค่ เซ็นชื่อ แพ็กเกจ เหมือนที่ Linux distribution อื่นแทบทั้งหมดทำกันมาตั้งแต่ยุค 90
อย่างน้อยทุกคนจะได้รู้ในระดับหนึ่งว่าโค้ดที่ build กันนั้นเป็นโค้ดเดียวกันที่บุคคลที่รู้ตัวตนส่งเข้ามาและตรวจทานแล้ว
ก่อนที่การเซ็นชื่อจะกลายเป็นมาตรฐาน คงนึกภาพยากว่าจะใช้ Nix ในงานโปรดักชันที่ปกป้องสิ่งมีค่าอะไรสักอย่าง
ส่วนใหญ่ไม่ได้ให้การรับประกันใด ๆ เกี่ยวกับเนื้อหาของแพ็กเกจ
การคาดหวังการรับประกันที่มีความหมายจากลายเซ็นของพวกเขาให้ความรู้สึกคล้ายกับการคาดหวังบริการสนับสนุนผลิตภัณฑ์จากพนักงานส่งของ
ไม่จำเป็นต้องเชื่อด้วยซ้ำว่าแพ็กเกจไม่ได้ถูกแพ็กอย่างมุ่งร้าย
Nix ทำ build ที่ทำซ้ำได้ ดังนั้นถ้าไม่อยากพึ่งพา binary cache ก็ดู derivation แล้ว build เองได้
สุดท้ายแล้วเนื้อหาพื้นฐานมีเจตนาร้ายหรือไม่เป็นเรื่องระหว่างนักพัฒนากับผู้ใช้
ถ้า distribution อื่นทำให้เชื่อในทางตรงกันข้าม ผมคิดว่านั่นค่อนข้างเป็นการชี้นำผิด
ข้อยกเว้นที่นึกออกคือ Tails แต่ Tails ก็ไม่ได้กว้างเท่า Nix
เท่าที่เห็น Debian ไม่ทำแบบนั้นแล้ว แต่ระบบ build เป็นผู้เซ็นชื่อ build แทน, Fedora ก็ไม่ทำ, ส่วน Arch ไม่แน่ใจแต่ดูเหมือนจะไม่ทำ
ระบบ build ของ NixOS เซ็นชื่อผลลัพธ์ build ทั้งหมดด้วยคีย์ของตัวเองและตรวจสอบลายเซ็นตอนดาวน์โหลด
ถ้ามองแบบหวาดระแวง Nix ก็อย่างน้อยทำให้การ build ทุกอย่างจากซอร์สเอง เป็นเรื่องง่าย
เป็นหมุดหมายที่น่าประทับใจมาก และขอแสดงความยินดีกับคนที่ทำให้เป็นไปได้
แม้ตอน build ISO ใหม่จริง ๆ ก็ยังมีความแตกต่างเกิดขึ้น และระบุว่าสาเหตุมาจากปัญหาที่ยังเหลือใน cache ของ Hydra กับวิธีสร้าง ISO
อยากรู้ว่ามีใครอธิบายได้ไหมว่าแก้ “วิธีที่ ISO ถูกสร้างขึ้น” อย่างไร
ก่อนหน้านี้เคยพยายามทำ ISO ที่ทำซ้ำได้ แต่ไม่สามารถทำให้ระบบไฟล์สร้าง extent แบบกำหนดแน่นอนได้
ขั้นตอนสุดท้ายของกระบวนการนั้นสร้าง ISO ในไดเรกทอรี
./result/isoสิ่งที่ตามหาเหมือนจะเป็นคำสั่งที่ build นั้นเรียกใช้ แต่ไม่แน่ใจว่ากำลังหาขั้นตอนไหนอยู่
เช่น การเรียก
xorrisoอยู่ที่นี่: https://github.com/NixOS/nixpkgs/blob/master/nixos/lib/make-...ถ้าจะทำแบบนี้ ไม่ต้องหลอก เวลาระบบ ด้วยหรือ?
เวลามักเข้าไปอยู่ในไบนารีไม่ทางใดก็ทางหนึ่ง
พบบ่อยมากจน compiler จำนวนมาก implement ตัวแปรกึ่งมาตรฐานสำหรับหลอก timestamp คือ SOURCE_DATE_EPOCH: https://reproducible-builds.org/docs/source-date-epoch/
นี่ช่วยแก้ปัญหาที่ Ken Thompson เขียนไว้ใน “Reflections on Trusting Trust” ไม่ใช่หรือ?
ถ้าสามารถ bootstrap ทั้งระบบจาก source code ได้อย่างสมบูรณ์ ก็น่าจะยากขึ้นที่จะใส่อะไรอย่าง compiler ที่ถูกฝัง backdoor
ในทางทฤษฎี อาจมี backdoor ที่ซับซ้อนอยู่ใน environment ที่ใช้ build ISO ก็ได้
ถ้าอยากแก้ปัญหานั้นจริง ๆ ลองดู Diverse Double Compiling(https://dwheeler.com/trusting-trust/) หรือการ bootstrap environment ทั้งหมด(https://bootstrappable.org/)
หัวข้อ “แนวทางข้างต้นไม่มีปัญหา bootstrap หรือ?” ในบทความก็เกี่ยวข้องเช่นกัน
ถึงอย่างนั้น แค่การทำซ้ำ build ก็ช่วยมากในการทำให้การโจมตีแบบนั้นมีโอกาสเกิดขึ้นน้อยลงเรื่อย ๆ
ช่วงหลังจากงาน ทำให้อยู่ใน ecosystem ของ Red Hat
เลยอยากรู้ว่าสิ่งนี้เทียบกับ Fedora Silverblue, Ansible, Fedora Silverblue + Ansible แล้วเป็นอย่างไร
Imagebuilder อ้างว่าสามารถทำซ้ำได้ แต่เท่าที่ผมทราบ ส่วนใหญ่ติดตั้งแพ็กเกจ rpm เป็นไบนารี ไม่ใช่จากซอร์ส
ดังนั้นถ้าแพ็กเกจอินพุตทั้งหมดไม่ได้ทำซ้ำได้ด้วย ก็ไม่ใช่ความสามารถในการทำซ้ำอย่างเคร่งครัด
ถ้าคำอธิบายเรื่องการ build แพ็กเกจจากซอร์ส การสร้างอิมเมจ distribution และการจัดการความสามารถในการทำซ้ำยังไม่ค่อยเข้าใจ คุณก็น่าจะไม่ใช่กลุ่มผู้อ่านหลัก
ในขณะที่ Ansible ระบุขั้นตอนที่ OS ต้องทำตาม
Silverblue กับ Nix แทบจะเป็นคนละแนวทางกัน นอกจากข้อเท็จจริงที่ว่าทั้งคู่เป็นดิสโทร Linux
Silverblue เป็นความพยายามที่จะเปลี่ยนวิธีส่งมอบซอฟต์แวร์ โดยใช้เฉพาะคอนเทนเนอร์บนโฮสต์ที่เปลี่ยนแปลงไม่ได้
ถ้ากำลังมองหาทางเลือกแทน Ansible ที่เลียนแบบ Nix ได้ในระดับหนึ่งโดยใช้ Jsonnet และการติดตามสถานะ Etcha ก็น่าดู: https://etcha.dev
Nix เป็นแบบเปลี่ยนแปลงไม่ได้
การเปลี่ยนแปลงใหม่จะถูกสร้างขึ้นใหม่ทั้งหมด และหลังจาก build สำเร็จแล้วเท่านั้น แพ็กเกจทั้งหมดจึงจะถูก “ลิงก์สัญลักษณ์” เข้ากับระบบปัจจุบัน
Fedora Silverblue มีพื้นฐานบน ostree https://github.com/ostreedev/ostree
มันทำงานคล้ายกับ git สำหรับ root tree แต่หากต้องการนำการเปลี่ยนแปลงไปใช้ ต้องรีบูตทั้งระบบ
Nix ใช้วิธีลิงก์แพ็กเกจด้วย symbolic link จึงไม่จำเป็นต้องรีบูตระบบ
มีคำอธิบายที่ละเอียดกว่านี้อยู่ที่นี่: https://dataswamp.org/~solene/2023-07-12-intro-to-immutable-...