Debian ต้องจัดเตรียมแพ็กเกจที่ทำซ้ำได้

 (lists.debian.org)
1 คะแนน โดย GN⁺ 5 시간 전 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • ทีมรีลีสของ Debian ตัดสินใจในช่วงกึ่งกลางของรอบ forky ว่า จะต้องจัดเตรียม แพ็กเกจที่ทำซ้ำได้
  • ซอฟต์แวร์ migration จะบล็อก แพ็กเกจใหม่ ที่ไม่สามารถทำซ้ำได้บน reproduce.debian.net
  • แม้แต่แพ็กเกจเดิมใน testing หากเกิด การถดถอยด้านความสามารถในการทำซ้ำ ก็จะถูกบล็อกการ migration เช่นกัน
  • มีการเพิ่มความสามารถให้ binNMU รัน autopkgtest ได้เช่นเดียวกับการอัปโหลดแบบ source-full
  • คิว CI มีขนาดใหญ่ขึ้นจากการเพิ่ม loong64 และการรีบิลด์แบบ multi-arch จึงต้องอาศัยความอดทน

บังคับใช้ความสามารถในการทำซ้ำของแพ็กเกจ Debian

  • ทีมรีลีสของ Debian ตัดสินใจที่จุดกึ่งกลางของรอบรีลีส forky ว่า Debian จะต้องจัดเตรียม แพ็กเกจที่ทำซ้ำได้
  • การตัดสินใจนี้เกิดขึ้นได้ด้วยแรงผลักดันจากความพยายามของโครงการ Reproducible Builds
  • ตั้งแต่เมื่อวาน ซอฟต์แวร์ migration ได้ถูกเปิดใช้งานให้บล็อกการ migration ของ แพ็กเกจใหม่ ที่ไม่สามารถทำซ้ำได้บน reproduce.debian.net
  • หากเกิด การถดถอยด้านความสามารถในการทำซ้ำ กับแพ็กเกจเดิมที่มีอยู่แล้วใน testing การ migration ก็จะถูกบล็อกเช่นกัน

การประกันคุณภาพและความรับผิดชอบของผู้อัปโหลด

  • การรัน autopkgtest สำหรับ testing binNMU

    • เมื่อต้นปีนี้ มีการเพิ่มความสามารถให้ซอฟต์แวร์ migration สามารถรัน autopkgtest สำหรับ binNMU ได้เช่นเดียวกับการอัปโหลดแบบ source-full
    • ความสามารถนี้อาจไม่ได้เกี่ยวข้องโดยตรงมากนักกับงานของผู้ดูแลส่วนใหญ่ แต่ถือเป็นอีกก้าวหนึ่งในการเสริมความเข้มแข็งของการประกันคุณภาพ

  • การเพิ่มสถาปัตยกรรม loong64 และคิว CI ที่เพิ่มขึ้น

    • เมื่อ 2 สัปดาห์ก่อน มีการเพิ่มสถาปัตยกรรมใหม่ loong64 เข้าไปใน archive
    • Debian อนุญาตให้มีการ migration ได้เฉพาะไบนารีที่สร้างโดย buildd เท่านั้น และด้วย ข้อกำหนด multi-arch ทำให้ต้องรีบิลด์แพ็กเกจจำนวนมากบนทุกสถาปัตยกรรม
    • เนื่องจากความสามารถของ binNMU ที่เพิ่มเข้ามาก่อนหน้านี้ ปัจจุบัน คิว CI จึงมีขนาดค่อนข้างใหญ่ และทีมรีลีสขอความอดทนเล็กน้อย

  • การติดตามผลหลังการอัปโหลด

    • ผู้อัปโหลดซอร์สแพ็กเกจมีหน้าที่รับผิดชอบในการทำให้แน่ใจว่าแพ็กเกจนั้นสามารถ migration ได้
    • หากแพ็กเกจถูกบล็อกเพราะ autopkgtest regression ของ reverse test dependency และจำเป็นต้องอัปเดต dependency นั้น ผู้อัปโหลดต้องยื่นบั๊กที่มีระดับความรุนแรง RC ที่เหมาะสม

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
GN⁺ 2 시간 전
ความเห็นจาก Hacker News

  • นี่เป็น ความสำเร็จครั้งใหญ่ ของ Debian และโลกของซอฟต์แวร์เสรี
    เพียงแต่กว่าจะทำให้ผู้คนเข้าใจว่ามันจำเป็นก็ใช้เวลาค่อนข้างนาน ตอนที่พูดใน debian-devel เมื่อปี 2007 ว่าสิ่งนี้จำเป็น ก็ได้รับคำตอบว่ามันเป็นการเสียเวลาอย่างมหาศาล และที่จริงกว่าจะมาถึงจุดนี้ได้ก็ต้องอาศัยงานมหาศาลจากผู้คนจำนวนมาก แต่ก็คุ้มค่าอย่างยิ่ง

    • ตั้งแต่ปี 2007 เป็นต้นมา Debian ไม่ได้มีบั๊กหรือการโจมตีใดที่ แพ็กเกจที่สร้างซ้ำได้ จะป้องกันได้
      ผมไม่คิดว่าคำว่า “คุ้มค่า” จะถูกต้อง นี่แค่ทำให้กำแพงการมีส่วนร่วมกับ Debian สูงขึ้นอีก และผมก็เห็นคนจำนวนมากบ่นอยู่แล้วว่าการมีส่วนร่วมกับ Debian นั้นยาก เมื่อก่อนยังพอปกป้องได้ว่า “ต้องมีการตรวจสอบและถ่วงดุลสารพัดเพื่อให้แพ็กเกจต่าง ๆ ทำงานเข้ากันได้ดี” แต่เรื่องนี้ดูเหมือนทำให้ยากขึ้นโดยแทบไม่มีเหตุผล และได้ประโยชน์เพียงเล็กน้อย

  • มีข้อมูลเพิ่มเติมที่ https://wiki.debian.org/ReproducibleBuilds บางส่วนอาจเก่าแล้ว แต่มีกราฟที่แสดง จำนวนแพ็กเกจที่ถูกบิลด์ใน CI และในนั้นมีเท่าไรที่เป็นบิลด์แบบสร้างซ้ำได้
    สีส้มหมายถึง FTBR หรือ “สร้างซ้ำได้แต่บิลด์ล้มเหลว” ผมไม่ค่อยถนัดอ่านตัวเลขจากกราฟ แต่ประเมินคร่าว ๆ ว่าน่าจะไม่กี่เปอร์เซ็นต์ ราว 4~5%

    • ของผมขึ้นแค่นี้:

      Forbidden

      You are not allowed to access this!
      เห็นแม้กระทั่งแท็ก HTML แบบดิบ ๆ :)
      แก้ไข: ผมยังเจอหน้า “I Challenge Thee” ในบันทึกด้วย หรือว่าถูก มาตรการกันบอต บล็อกอยู่? ทำไมล่ะ???

  • เป็นเรื่องที่ดีมาก NetBSD มีบิลด์ที่สร้างซ้ำได้อย่างสมบูรณ์มาตั้งแต่ปี 2017 แล้ว https://blog.netbsd.org/tnf/entry/netbsd_fully_reproducible_...

    • ตามที่ลิงก์ระบุไว้ NetBSD บรรลุสิ่งนั้นได้ด้วยความช่วยเหลือจาก Debian ถ้าผมเข้าใจถูก ไม่ใช่ว่า NetBSD ขยันกว่า แต่เป็นเพราะปัญหาง่ายกว่า มีแพ็กเกจน้อยกว่าและเปลี่ยนแปลงน้อยกว่า ยังใช้ CVS อยู่เลย จนคำว่า “เสถียร” ยังอธิบายได้ไม่พอ
      อีกอย่าง แพ็กเกจ Debian ส่วนใหญ่ก็เป็นบิลด์แบบสร้างซ้ำได้อยู่แล้ว ส่วนที่ยังไม่ใช่ ซึ่งมีประมาณ 5% จะแสดงเป็นสีส้มในกราฟนี้: https://wiki.debian.org/ReproducibleBuilds
    • ขอคุยโวหน่อยว่า stagex เป็นโครงการแรกที่ทำบิลด์แบบกำหนดผลได้และแยกสภาพแวดล้อมจากการบูตสแตรปด้วยซอร์สทั้งหมด 100% ได้สำเร็จเมื่อปีที่แล้ว และยังเป็นโครงการแรกที่บังคับให้ทุกรีลีสต้องมีการสร้างซ้ำที่ลงนามแล้วหลายชุด โดยผู้ดูแลต่างคนกันทำบนฮาร์ดแวร์ของตัวเอง
      Debian พัฒนาไปมากก็จริง แต่เวลาที่ Debian บอกว่าสร้างซ้ำได้ นั่นหมายความว่ายังดึงไบนารีจากบุคคลที่สามมาใช้ในการบิลด์ของตัวเอง ส่วนเวลาที่เราบอกว่าสร้างซ้ำได้ เราหมายถึงการบูตสแตรปจากซอร์สโค้ด 100% ไปจนสุดปลายของซัพพลายเชนซอฟต์แวร์ทั้งหมด
      ผมคิดว่าความแตกต่างนี้สำคัญ
      https://stagex.tools

  • ดีใจมากที่เห็นการเปลี่ยนแปลงนี้ หลังจากอ่านเรื่อง การโจมตี SolarWinds ในปี 2021 แล้วช็อกมาก จึงเริ่มมีส่วนร่วมกับ reproducible builds [1]
    ผมคิดว่าคำพูดของ Magnus Ihse Bursie ผู้ทำงานด้าน reproducible builds ของ OpenJDK เหมาะที่สุด: “ถ้าถามผม การที่คอมไพเลอร์และเครื่องมือบิลด์เริ่มสร้างเอาต์พุตที่ไม่กำหนดแน่นอนนั้น เดิมทีก็เป็นบั๊กตั้งแต่วันแรกอยู่แล้ว” [2]
    [1] https://www.linux.com/news/preventing-supply-chain-attacks-l...
    [2] https://github.com/openjdk/jdk/pull/9152#issue-1270543997

  • สงสัยว่าทำไมช่วงนี้เรื่องนี้ถึงกลายเป็นประเด็น ผมใช้ Yocto กับอุปกรณ์ฝังตัว และ reproducible builds ก็แทบจะทำได้เป็นเรื่องปกติอยู่แล้ว
    เปิดใช้การจัดการแพ็กเกจแบบ Debian ก็ทำได้ง่ายด้วย เลยรู้สึกว่าเหมือนทุกอย่างควรจะทำได้อยู่แล้วไม่ใช่หรือ

    • ผมสงสัยว่าคำว่า “ทำไมช่วงนี้ถึงเป็นประเด็น” หมายถึงอะไร
      reproducible builds เป็นแนวทางที่จำเป็นในงานคอมพิวติ้งอุตสาหกรรม ไม่ได้หมายความว่า Debian อยู่แนวหน้าของเรื่องนี้ แต่ใกล้เคียงกับการที่ Debian กำลังรับเอาแนวปฏิบัติทั้งอุตสาหกรรมที่ใช้กับระบบปฏิบัติการอื่น ๆ ซึ่งใช้ในงานระยะยาวและงานที่เกี่ยวข้องกับความปลอดภัย
      แน่นอนว่าส่วนหนึ่งที่วันนี้ใช้งานได้ง่าย ก็ต้องยกความดีความชอบให้กับงานยากจำนวนมากของทั้ง Yocto และนักพัฒนา Debian
      สิ่งที่น่าสนใจคือ ตอนนี้นักพัฒนา Debian กำลังผลักดันให้มันเป็นนโยบายเชิงรุกมากขึ้น จากสิ่งที่เป็นทางเลือกให้กลายเป็น บรรทัดฐานเริ่มต้น
    • ผมอยากรู้ว่ามีการตรวจสอบเชิงรุกจริงไหมว่าบิลด์นั้น สร้างซ้ำได้ในระดับบิต

  • สำหรับ amd64 forky
    reproduced: 97.02%
    good: 17586
    bad: 511
    fail: 30
    unknown: 0
    ดูสถิตินี้ สถิติของสถาปัตยกรรมอื่น ๆ และสาเหตุที่สร้างซ้ำไม่ได้ ได้ที่ https://reproduce.debian.net

  • ผมแปลกใจเสมอที่ Debian เป็นฝ่ายผลักดันเรื่องนี้ และไม่ใช่ ผู้ขายเชิงพาณิชย์ ทั้งที่องค์กรใหญ่ ๆ ที่จ่ายเงินให้ RHEL และ Ubuntu น่าจะเรียกร้องไบนารีที่ตรวจสอบได้อย่างจริงจัง

    • ถ้าคู่แข่งสามารถพิสูจน์ได้ว่าแพ็กเกจของตัวเอง เหมือนกันทุกบิต กับที่องค์กรใหญ่เผยแพร่ คู่แข่งรายนั้นก็จะได้ประโยชน์จากการรับรองความปลอดภัยขององค์กรใหญ่
      นี่ดีมากสำหรับซอฟต์แวร์เสรี แต่ไม่ค่อยดีนักสำหรับฝ่ายที่อยากเป็นเจ้าของแบบผูกขาด
    • reproducible builds มีไว้เพื่อลดความจำเป็นในการต้องเชื่อใจ แต่ผู้ขายเชิงพาณิชย์ทำ ธุรกิจจากการขายความน่าเชื่อถือ

  • Forbidden
    You don't have permission to access this resource.
    Apache Server at lists.debian.org Port 443
    :/
 
GN⁺ 5 시간 전
ความคิดเห็นจาก Lobste.rs

  • เป็นการเปลี่ยนแปลงที่ดีในแง่ความปลอดภัย ช่วงเปลี่ยนผ่านอาจยุ่งยาก แต่ท้ายที่สุดจะทำให้ ผู้ใช้ Debian Linux ทั่วโลกได้รับความน่าเชื่อถือที่สูงขึ้น

  • สงสัยว่าประโยชน์หลักสำหรับโปรเจกต์อย่าง Debian คืออะไร ต้องการให้ทุกคนมี หลักฐานว่าไม่มี backdoor อยู่ในไบนารีใช่ไหม?
    กล่าวคือเป็นการลดความเชื่อใจที่ต้องมอบให้ผู้ดูแลแพ็กเกจ และลดความเสี่ยงจากผู้ดูแลที่มุ่งร้ายด้วยหรือเปล่า ไม่ได้สงสัยในเชิงต่อต้าน แค่ยังไม่เข้าใจ 100% ว่าทำไม Debian ถึงใช้เวลากับเรื่องนี้มาก การทำให้บิลด์ reproducible ได้ดูทั้งยากและใช้แรงมากพอสมควร

    • ไม่ใช่แค่ backdoor แต่ยังช่วยตรวจสอบได้ด้วยว่ามี การดัดแปลงหรือแก้ไข ทั่วไปหรือไม่ เรื่องนี้ช่วยด้านความปลอดภัย และยังเป็นประโยชน์ต่อการพัฒนาโปรเจกต์ด้วย เพราะแพ็กเกจที่บิลด์แบบ reproducible และค่อนข้างปิดล้อมจะมีโอกาสพังแปลก ๆ บนสภาพแวดล้อมของนักพัฒนาคนอื่นน้อยลง
      แก่นสำคัญคือการสร้างหลักฐานว่าซอร์สโค้ดที่ใช้สร้างแพ็กเกจผลลัพธ์นั้นเป็นซอร์สโค้ดชุดนั้นจริง ๆ ไม่ใช่มีซอร์สอีกชุดที่ซ่อนอยู่ the reproducible-builds org has a bit of a 'why' which puts it better than i can
      การทำให้บิลด์ reproducible ได้นั้นยากมาก ตัวอย่างเช่น timestamp ใน pipeline การคอมไพล์ ก็ทำให้เกิดความต่างได้ เช่นเดียวกับ metadata ของ archive ที่สร้างขึ้น สิ่งเหล่านี้ต้องถูกกำจัดออกทั้งหมด และในบางกรณีก็ต้องมี แพตช์ต่อโปรเจกต์ต้นน้ำ เช่น CMake หรือคอมไพเลอร์ Go ไม่ใช่แค่ตัวแพ็กเกจเอง หลายกรณีในอดีตปัญหาแบบนี้ไม่เคยถูกนำมาพิจารณาด้วยซ้ำ จึงต้องทำงานครอบคลุมทั้ง build stack อย่างไรก็ตาม งานนี้ดำเนินมานานแล้ว ดังนั้นส่วนโครงสร้างพื้นฐานระดับล่างจำนวนมากจึงเสร็จไปแล้วหรือคืบหน้าไปมาก
    • ไม่คิดว่านี่ควรเป็นลำดับความสำคัญสูงสุดของ Debian แต่ Debian ก็ไม่ได้ขับเคลื่อนแบบนั้น ผู้คนทำ สิ่งที่ตัวเองอยากทำ และลำดับความสำคัญส่วนบุคคลก็มักไม่สอดคล้องกับลำดับความสำคัญที่สมเหตุสมผลในระดับโปรเจกต์เสมอไป

  • ความสามารถในการทำซ้ำได้ ที่ Debian พูดถึง เป็นแนวคิดเดียวกับที่พูดกันใน NixOS หรือเปล่า?

    • ไม่ใช่ NixOS is not reproducible เป็นบทอ้างอิงมาตรฐาน
    • ดิสโทรที่ติดตามเรื่อง reproducible builds เป็นโปรเจกต์ต่างก็มักมุ่งไปยังเป้าหมายเดียวกัน reproducible-builds.org ติดตามโปรเจกต์ที่กำลังทำเรื่องนี้อย่างจริงจังใน pipeline การแพ็กเกจ
      NixOS เองก็กำลังทำ reproducible builds อยู่ และถ้าจำไม่ผิด อย่างน้อย ISO นั้น reproducible ได้ 100% ทั้งตอนบิลด์และตอนรันไทม์ แต่สิ่งที่คนมักหมายถึงเมื่อพูดถึงความ reproducible ของ NixOS ไม่ใช่ “reproducible builds” ที่กำลังคุยกันอยู่ตรงนี้ ลองดูบทความของ foxboron ที่ลิงก์ไว้ในคอมเมนต์คู่ขนานของเธรดนั้น มันใกล้เคียงกับความสามารถในการทำซ้ำของสภาพแวดล้อม หรือ “deterministic build” มากกว่า ซึ่งยังมีคุณค่าอยู่ แต่ไม่ใช่ประเด็นที่กำลังพูดถึงที่นี่

  • ตอนนี้ฟังดูเหมือนใช้ แนวทางแบบ ratchet อยู่ ของที่ไม่เคยบิลด์แบบ reproducible ได้มาก่อนก็ยังอนุญาตอยู่ใช่ไหม?

    • ถ้าแพ็กเกจบิลด์แบบ reproducible ไม่ได้ ก็จะไม่ถูกรวมใน Debian release ถัดไป นั่นหมายความว่าแพ็กเกจที่ “ไม่เคยบิลด์แบบ reproducible ได้เลย” อาจยังอยู่ใน Debian unstable ได้ แต่โดยทั่วไปก็ไม่ได้มองว่าดีเท่าไรที่จะคงแพ็กเกจที่ไม่มีทางไปถึง stable ไว้ใน Debian unstable ต่อไป อย่างไรก็ตาม เท่าที่ทราบไม่ได้มีกฎที่บังคับใช้แบบเชิงกลไก