Arch Linux เห็นว่าสามารถควบคุมเหตุมัลแวร์ได้แล้ว: กระทบแพ็กเกจกว่า 1,500 รายการ

• ใน คลัง AUR ที่ผู้ใช้มีส่วนร่วม ของ Arch Linux พบแพ็กเกจที่ติดมัลแวร์มากกว่า 400 รายการในตอนแรก ก่อนที่ตัวเลขสุดท้ายจะเพิ่มเป็นมากกว่า 1,500 รายการ
• ในอัปเดตก่อนหน้าเมื่อไม่กี่ชั่วโมงก่อน ระบุว่าแพ็กเกจที่ติดจากเหตุการณ์สัปดาห์นี้มีประมาณ 900 รายการ
• หลังจากนั้นนักพัฒนา Arch Linux ได้ลบ คอมมิตอันตราย ที่รับทราบแล้วทั้งหมด และนับจำนวนแพ็กเกจที่ได้รับผลกระทบได้ 1,579 รายการ
• รายการ 1,579 รายการนี้ก็ยังถูกระบุว่าเป็น รายชื่อจำนวนมากแต่ไม่ใช่ทั้งหมด ของแพ็กเกจที่ได้รับผลกระทบ จึงเป็นไปได้ว่าขอบเขตทั้งหมดอาจกว้างกว่านี้
• ซอฟต์แวร์จำนวนมากในคลังที่ผู้ใช้เป็นผู้ดูแลได้รับผลกระทบจาก เหตุการณ์ด้านความปลอดภัย ครั้งนี้ และในอัปเดตแยกยังมีการโจมตีด้วยมัลแวร์ที่ซับซ้อนยิ่งขึ้นเกิดขึ้นอีก

---

ภาพรวมเหตุการณ์

• เหตุการณ์เริ่มขึ้นเมื่อพบแพ็กเกจที่ติดมัลแวร์มากกว่า 400 รายการใน คลัง AUR ที่ผู้ใช้มีส่วนร่วม สำหรับผู้ใช้ Arch Linux
• เมื่อใกล้สิ้นสุดวัน ทาง Arch Linux เห็นว่าคอมมิตที่ได้รับผลกระทบทั้งหมดได้รับการจัดการแล้ว แต่จำนวนแพ็กเกจที่ได้รับผลกระทบเพิ่มขึ้นเป็นมากกว่า 1,500 รายการ
• เหตุการณ์ครั้งนี้เป็น เหตุการณ์ด้านความปลอดภัย ที่ส่งผลต่อซอฟต์แวร์จำนวนมากในคลัง Arch Linux ที่ผู้ใช้เป็นผู้ดูแล

การเปลี่ยนแปลงของขอบเขตผลกระทบ

• ในอัปเดตก่อนหน้าเมื่อไม่กี่ชั่วโมงก่อน ระบุว่าเหตุการณ์ในสัปดาห์นี้ทำให้มีแพ็กเกจประมาณ 900 รายการ ติดมัลแวร์
• หลังจากนั้น ตามข้อความล่าสุดในเธรดเหตุการณ์ด้านความปลอดภัย นักพัฒนา Arch Linux ได้ลบคอมมิตอันตรายที่รับทราบแล้วทั้งหมด
• รายการที่ถูกอ้างถึงระบุจำนวนแพ็กเกจที่ได้รับผลกระทบจากมัลแวร์ไว้ที่ 1,579 รายการ

ความไม่แน่นอนที่ยังเหลืออยู่

• แม้แต่รายการที่แสดงแพ็กเกจ 1,579 รายการก็ยังถูกระบุว่าเป็น “รายชื่อจำนวนมากแต่ไม่ใช่ทั้งหมดของแพ็กเกจที่ได้รับผลกระทบ”
• ดังนั้น ตัวเลขที่เปิดเผยออกมาจึงแสดงให้เห็นขอบเขตผลกระทบขนาดใหญ่ที่ยืนยันแล้ว แต่ตัวรายการเองก็ยังครอบคลุมแพ็กเกจทั้งหมดไม่ครบ

อัปเดตเพิ่มเติม

• มีอัปเดตแยกเพิ่มเติมว่าคลัง Arch Linux AUR ได้เผชิญกับการโจมตีด้วยมัลแวร์ที่ซับซ้อนยิ่งขึ้นอีกระลอกหนึ่ง

[GN⁺]

ความคิดเห็นจาก Hacker News

• สงสัยว่าทีม AUR เคยเผยแพร่ การวิเคราะห์หลังเหตุการณ์ หรือไม่
  การรับมือครั้งนี้เร็วได้น่าประทับใจ แต่พูดตรง ๆ คือดูเหมือนว่าทั้งนโยบาย AUR และตัว wrapper จำเป็นต้องเปลี่ยน
  ควรตั้งอายุขั้นต่ำของแพ็กเกจได้แบบ pnpm และไม่ควรให้ใครก็รับแพ็กเกจ orphan ไปดูแลต่อได้
  การรับไปดูแลต่อควรมีการจำกัดอัตราในระดับรวมเพื่อใช้เป็นสัญญาณการโจมตีได้ และก็ควรมีการสแกนช่องโหว่ตอนเผยแพร่เหมือนที่หลายบริษัททำใน NPM
  อย่างไรก็ตาม การเปลี่ยนแปลงส่วนใหญ่แบบนี้ดูจะเป็นงานของตัวช่วยแพ็กเกจและบุคคลที่สามมากกว่าผู้ดูแล AUR

  • แบ่งแพ็กเกจ AUR ตาม namespace น่าจะดีกว่า
    แบบนั้นความเป็นเจ้าของจะไม่หายไป จึงไม่จำเป็นต้องมีการทำให้เป็น orphan ตั้งแต่แรก
  • ไม่มีเครื่องมือทางการสำหรับดาวน์โหลด AUR repository ดังนั้นส่วนนั้นจึงขึ้นอยู่กับวิธีที่แต่ละคนใช้
  • ได้ลองทำแพตช์ให้ pakku ใส่ อายุขั้นต่ำของ AUR โดยได้แรงบันดาลใจจาก pnpm ไม่นานนี้ [1]
    [1] https://github.com/gavinhungry/patches/blob/main/pakku/pakku...
    [2] https://github.com/zqqw/pakku
  • ถ้าจำกัดการรับแพ็กเกจ orphan ไปดูแลต่อมากเกินไป แพ็กเกจที่ควรได้รับการดูแลจริง ๆ ก็อาจถูกปล่อยทิ้งไว้
    ควรมีข้อจำกัด แต่เช่น จำกัดเป็น รับไปดูแลต่อได้เดือนละ 1 แพ็กเกจ สำหรับผู้ใช้ที่สมัครมานานระดับหนึ่งก็น่าจะพอดี
    ยังไงก็ตาม คนที่ปล่อยให้อัปเดตแพ็กเกจ AUR ที่ติดตั้งในเครื่องแบบอัตโนมัติและไม่ตรวจทานก็คงแทบไม่มีอยู่แล้ว ดังนั้นพื้นผิวการโจมตีก็เล็กพอสมควร
  • แค่ สแกนช่องโหว่ อย่างเดียวน่าจะจับไม่ได้
    แก่นของเวิร์ม miasma คือการที่ลายเซ็นและวิธีของตัวช่วยเปลี่ยนเร็วเกินไป
    มัลแวร์ implant ที่เข้ารหัสจะถอดรหัส payload ด้วยคีย์ AES-128-GCM ที่ต่างกันไปตามตำแหน่ง GitHub ที่อัปโหลด และชื่อเมธอดในโค้ดก็เปลี่ยนแบบไดนามิก พร้อมทั้งสุ่มใช้ encrypted symbol offset ซ้ำด้วย
    มันเป็นมัลแวร์แบบกลายพันธุ์ จึงเป็นคู่ต่อสู้ที่แย่มากสำหรับเครื่องมือที่อาศัยลายเซ็น
    ดูเหมือน APT28/29 จะพึ่งพาอยู่พอสมควรกับความช้าที่ Microsoft บล็อกผู้ใช้และ repository บน GitHub ที่ถูกใช้เป็นโครงสร้างพื้นฐาน C2 แบบอัตโนมัติ
    น่าคิดว่าสิ่งนี้หมายความว่าอย่างไรต่อกลยุทธ์ความปลอดภัย
    พอถึงจุดที่สแกนลายเซ็นหรือสตริงได้ ก็เข้าสู่เกมแมวจับหนูกับ botnet อัตโนมัติเต็มรูปแบบไปแล้ว และไม่มีทางชนะ
    ตลอดสัปดาห์ที่ผ่านมา เครื่องมือด้าน supply chain ที่ตามการเปลี่ยนแปลงของ implant นี้ทันมีแค่ socket.dev โดยเครื่องมืออื่น ๆ ไม่รู้จัก Miasma ด้วยซ้ำ และเพิ่งมาค้นพบซ้ำว่าเป็นแคมเปญใหม่
    ทั้งกำลังคนและ toolchain ไม่พอจะ reverse engineer payload ได้เร็วพอที่จะตาม adapter สำหรับ ecosystem ใหม่ที่โผล่มาทุก 24 ชั่วโมงทัน
    คำว่าอัตโนมัติเต็มรูปแบบในที่นี้หมายถึง ใน package ecosystem อื่น ๆ มีการนำ credential ที่ขโมยมาไปใช้แล้วภายในไม่ถึง 48 ชั่วโมง
    มีอีเมลและชื่อบางชุดโผล่มาซ้ำ ๆ ซึ่งดูเหมือนเป็นคนที่อาจยังไม่เข้าใจผลกระทบของเวิร์มที่แพร่กระจายตัวเองนี้
    ตัวอย่างเช่น ตัวชี้วัดการถูกเจาะที่มองหาแพ็กเกจที่พึ่งพา bun ก็ช่วยอะไรไม่ได้มาก
    มัลแวร์แค่ดาวน์โหลดกลับมาใหม่ผ่านวิธีภายนอกก็พอ
    ในแคมเปญ PyPI ครั้งที่สอง หลังจากที่คลื่นแรกของ dropper มัลแวร์จากแคมเปญ RedHat ถูกทำเครื่องหมายให้ผู้ดูแล PyPI เห็น ก็มีการเปลี่ยนไปใช้ไฟล์ WHL แบบบีบอัดและไฟล์ setup.pth ที่รันอัตโนมัติเพื่อดาวน์โหลด dropper แทน
    หาก package manager ของ ecosystem เหล่านี้ไม่ได้ถูกเขียนใหม่ตั้งแต่ต้นโดยยึด chroot, sandbox, network·domain log และ allowlist รายการต่อรายการเป็นพื้นฐาน กลยุทธ์แจกจ่ายมัลแวร์ผ่านการโจมตี supply chain ก็จะยังใช้ได้จริงต่อไป
    repository ของเครื่องมือบรรเทาความเสี่ยงอยู่ที่ [1] และรายละเอียดเชิงเทคนิคอยู่ในบล็อกโพสต์ [2]
    Composer, Rubygems, NPM, PyPI และ Go ต่างก็ได้รับผลกระทบเช่นกัน เป็นปัญหาที่ครอบคลุม package manager ทุกตัว
    ควรมีการพูดคุยกันอย่างเปิดเผยกว่านี้ว่าเราแบกความประมาทและความไว้วางใจต่อภายนอกไว้มากแค่ไหนในบรรดา package manager ทั้งหลาย และเรื่องนี้ควรต้องเปลี่ยนจริง ๆ
    [1] https://github.com/cookiengineer/antimiasma
    [2] https://cookie.engineer/weblog/articles/malware-insights-mia...

• ตอนที่เริ่มมี pacman wrapper ที่ติดตั้งได้ตรงจาก AUR มันทำให้รู้สึกไม่สบายใจมาก
  เคยติดตั้งของจาก AUR อยู่บ้าง แต่ส่วนใหญ่ยังชอบข้ามขั้นกลางแล้วไปที่เว็บไซต์ของโปรเจกต์โดยตรงมากกว่า
  PKGBUILD ที่เตรียมไว้ล่วงหน้าไม่ได้สะดวกถึงขั้นคุ้มกับความเสี่ยงจากการยึดชื่อพิมพ์ผิดหรือการอาศัยช่องพึ่งพา npm·pip ในทางที่ผิด

  • wrapper อย่าง yay จะแสดง diff ของ PKGBUILD ทุกครั้งที่อัปเดต
    ตอนติดตั้งครั้งแรกก็ตรวจ URL และดูว่าสคริปต์ติดตั้งต่าง ๆ สมเหตุสมผลหรือไม่ แล้วหลังจากนั้นการอัปเดตส่วนใหญ่ก็เปลี่ยนแค่เลขเวอร์ชันกับ checksum
    การโจมตีแบบยึดชื่อพิมพ์ผิดน่าจะเห็นได้ค่อนข้างชัด
    ตอนติดตั้งครั้งแรกอาจเปราะบางอยู่บ้าง แต่การไปที่เว็บไซต์โปรเจกต์แล้วกดดาวน์โหลดก็ไม่ต่างกัน
  • Arch มักถูกวิจารณ์ว่าเป็นพวกหัวสูงหรือกันผู้ใช้ทั่วไปออกไป แต่การ ไม่ทำให้เรื่องเสี่ยงกลายเป็นเรื่องง่าย นั้นมีข้อดีชัดเจน
    หลายด้านของชีวิตก็เป็นแบบเดียวกัน
    หลังจากใช้ Void Linux ก็เปลี่ยนมาใช้ aurutils บน Arch เพื่อแยกส่วนคล้ายกัน
    มันทำให้ build เองและดูแล local AUR repository ได้ง่าย แล้วค่อยติดตั้ง·จัดการด้วย pacman ซึ่งช่วยให้กระบวนการอัปเกรดทั้งหมดดีขึ้น
  • สำหรับฉัน การประนีประนอมแบบนี้ไม่มีค่าอะไร
    เหตุผลที่ย้ายมา Linux ไม่ใช่เพื่อเสียเวลาไปกับการเข้าเว็บไซต์แล้วกด “download” เพื่ออัปเดตโปรแกรมแบบผู้ใช้ Windows
    แต่ pacman wrapper ที่พูดถึงก็ยังดูเสี่ยงอยู่ดี
  • AUR และ repository คล้ายกันของดิสโทรอื่น ๆ ให้ความรู้สึกน่ากลัวจริง ๆ
    บทแนะนำที่ใช้ repository พวกนี้แพร่หลายมากจนแทบทำให้รู้สึกว่าตัวเองเป็นคนประหลาดที่ไม่อยากให้สิทธิ์ root แบบไม่มีกำหนดกับคนแปลกหน้าที่แทบไม่มีการตรวจทานโดยเพื่อนร่วมวงการ
    ทั้งหมดนี้เพื่อจะติดตั้งแพ็กเกจเวอร์ชันหนึ่งที่อาจไม่ต้องอัปเดตเลยหรือแทบไม่ต้องอัปเดต

• ลองอ่านแบบเร็ว ๆ แล้วดูเหมือนว่ามีการติดตั้ง atomic-lockfile, js-digest, lockfile-js จาก npm
  รายการแพ็กเกจที่ได้รับผลกระทบอยู่ใน [1]
  ผมหาวิธีตรวจสอบระบบโดยตรงไม่เจอ เลยลองใช้ pacman -Qmi เพื่อหาข้อมูลเกี่ยวกับแพ็กเกจภายนอกและวันที่ที่เกี่ยวข้อง
  จากนั้นก็นำผลลัพธ์ไปเทียบกับรายการแพ็กเกจที่ได้รับผลกระทบได้
  นอกจากนี้ยังสามารถค้นหาไฟล์ในหลายตำแหน่งได้แบบนี้
  grep -rl "atomic-lockfile" / --include="package.json" --include="package-lock.json"
grep -rl "atomic-lockfile" ~/.npm 2>/dev/null
grep -i "atomic-lockfile" /var/log/pacman.log 2>/dev/null
  ไม่แน่ใจว่าหลังรันแล้วแพ็กเกจจะลบตัวเองหรือเปล่า
  ข้อมูลอื่น ๆ ไม่ค่อยช่วยเท่าไร เลยอยากแชร์อย่างน้อยก็คำสั่งพื้นฐานไว้
  [1] https://md.archlinux.org/s/SxbqukK6IA

  • วิธีที่ผมทำมีแบบนี้
    ใช้ yay เพื่อดึงรายชื่อแพ็กเกจที่ติดตั้งจาก AUR: yay -Qam > packages_aur.last
    ดาวน์โหลดรายการจาก https://md.archlinux.org/s/SxbqukK6IA#: curl https://md.archlinux.org/s/SxbqukK6IA/download > compromised.txt
    จากนั้นรัน grep -wFf compromised.txt packages_aur.last ก็จะได้แพ็กเกจที่อยู่ในทั้งสองไฟล์ หรือก็คือแพ็กเกจที่น่าจะเคยถูกฝังโค้ดอันตรายในช่วงใดช่วงหนึ่ง
  • ผู้โจมตีใช้ Node dependencies อย่างน้อยสามตัว ดังนั้นตรวจแค่ atomic-lockfile อย่างเดียวไม่พอ
    ยังมี js-digest กับ lockfile-js ด้วย และในช่วงหนึ่งก็เปลี่ยนจาก npm ไปใช้ bun
  • อันนี้ก็น่าดูเหมือนกัน: https://github.com/lenucksi/aur-malware-check
  • ตลกดีที่แม้จะพยายามใส่มัลแวร์ลงใน Arch Linux AUR แต่สุดท้ายมัลแวร์ก็ยังถูกแจกจ่ายผ่าน NPM อยู่ดี
    เป็นแพลตฟอร์มระดับตำนานจริง ๆ
  • ไม่เข้าใจว่า emacs-magit ได้รับผลกระทบได้อย่างไร
    เท่าที่ผมรู้มันไม่มี JavaScript เลย

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

  • จะให้ “ตรวจสอบ” อย่างไร
    หมายถึงต้องอ่านโค้ดทุกบรรทัดก่อนติดตั้งหรือ
    แล้วถ้าเป็นแพ็กเกจไบนารีล่ะ
    จะให้สร้าง reproducible builds สำหรับทุกอย่างที่ติดตั้ง หรือให้ย้ายไปใช้ดิสโทรแบบ source-based แทนหรือ
    การโยนความรับผิดชอบนี้ให้ผู้ใช้ไม่ใช่ทางแก้ที่ยั่งยืน
    เรื่องสามัญสำนึกก็มีส่วนอยู่บ้าง แต่จะโทษผู้ใช้แบบนี้ไม่ได้
  • ฟังดูเข้าท่า แต่สุดท้ายก็เป็นคำแนะนำที่ทำจริงไม่ได้ จนไม่ใช่แค่ไร้ประโยชน์แต่กลับเป็นโทษด้วย
    โลกนี้มีโค้ดมากเกินกว่าที่คนคนหนึ่งจะอ่านได้หมดตลอดชีวิต
    มีโอกาสสูงที่ตัวคุณเองก็ยังไม่เคยอ่านแม้แต่ 1% ของซอร์สโค้ดที่กำลังรันอยู่บนคอมพิวเตอร์ตอนนี้
    ถ้าอย่างนั้นคุณเลิกใช้คอมพิวเตอร์ไปแล้วหรือยัง
    แล้วคุณจะเชื่อถือสิ่งที่เกิดขึ้นข้างในนั้นได้อย่างไร
  • ผมคิดว่าจุดยืนแบบ “ต้องตรวจสอบก่อนติดตั้งเสมอ” ควรถูกทบทวนใหม่
    นักพัฒนา Arch Linux ทำงานได้ยอดเยี่ยมและส่วนตัวก็รู้สึกขอบคุณ แต่ในยุคที่ supply chain attack เพิ่มขึ้นแบบนี้ ผมรู้สึกว่าการมีแค่ คำเตือนถึงผู้ใช้ นั้นถึงขีดจำกัดมานานแล้ว
    ยังมองไม่เห็นวิธีแก้ที่ง่าย แต่การมีมาตรการอย่าง peer review ก่อนเผยแพร่ หรือช่วงหน่วงเวลา อาจช่วยบรรเทาปัญหาได้บ้าง
  • AUR เคยถูกยกย่องมานานว่าเป็นจุดแข็งใหญ่ของ Arch แต่ความสะดวกนั้นก็มีราคาที่ต้องจ่าย
    การที่ผู้โจมตีสามารถทำเครื่องหมายแพ็กเกจว่าเป็นแพ็กเกจกำพร้า รอ 2 สัปดาห์ แล้วถ้าผู้ดูแลเดิมกำลังลาพักจนไม่ตอบ ก็จะได้สิทธิเป็นผู้ดูแลและปล่อยอัปเดตเผ็ดร้อนออกมาได้ เป็นอะไรที่ไม่น่าเชื่อ
  • ผมมองว่านี่เป็นกรณีตัวอย่างที่สนับสนุนอย่างมากต่อการใช้ ไฟล์ระบบแบบ immutable, การติดตั้งแบบ local ให้ผู้ใช้เป็นค่าปริยาย และการให้สิทธิ์ขั้นต่ำเท่าที่จำเป็นแก่คอมโพเนนต์กับโปรแกรม
    ดิสโทรแบบ immutable, Wayland และ Flatpak มีชิ้นส่วนบางอย่างของแนวทางนี้อยู่แล้ว แต่ยังมีช่องโหว่สำคัญเหลืออยู่
    ปัญหาใหญ่ที่สุดคือ sandboxing ถูกผูกติดกับรูปแบบแพ็กเกจ ซึ่งผมคิดว่าเป็นความผิดพลาด
    sandboxing และสิทธิ์การเข้าถึงควรเป็นความสามารถระดับระบบ เพื่อให้แม้แต่ไบนารีสุ่ม ๆ ก็หลุดรอดผ่านช่องว่างได้ยาก
    ถึงจะไม่แก้ปัญหาได้ทั้งหมด แต่ก็ช่วยลดขอบเขตความเสียหายได้มาก และทำให้ผู้ใช้ดิสโทรเป็นเป้าหมายที่ไม่น่าดึงดูดเท่าเดิม

• สำหรับคนที่กังวล ผมเจอรีโพซิทอรีที่รวบรวมสคริปต์และรายการแพ็กเกจล่าสุดไว้เพื่อช่วยตรวจว่าติดเชื้อหรือไม่: https://github.com/lenucksi/aur-malware-check

  • ผมเอารายการเดียวกันนี้ (https://md.archlinux.org/s/SxbqukK6IA) ไปให้ Claude ช่วย ตรวจมัลแวร์ ดูแล้ว ซึ่งมันก็ทำการตรวจสอบโดยเนื้อแท้แบบเดียวกับที่สคริปต์นี้ทำ
    ใช้อันไหนก็น่าจะเพียงพอเหมือนกัน

• ฉันไม่ได้ใช้ Arch Linux แต่ใช้ NodeJS เยอะ และฝั่งนั้นก็เจอการโจมตีคล้าย ๆ กันบ่อย
  ช่วงนี้เลยสงสัยว่ามีที่ไหนบ้างที่ทำ การจัดการแพ็กเกจ ได้อย่างถูกต้องและปลอดภัยจริง ๆ

  • AUR เป็นระบบที่พึ่งพาการสนับสนุนจากผู้ใช้ จึงมักมีมัลแวร์ปะปนเข้ามาในแพ็กเกจได้เป็นครั้งคราว
    แม้ครั้งนี้จะไม่ใช่เหตุการณ์ขนาดใหญ่แบบนี้ แต่เดิมทีก็เห็นชัดอยู่แล้วว่ามันไม่ปลอดภัย และมีคำเตือนเรื่องความเสี่ยงติดไว้ทั่วไป
  • ดิสโทร Linux ต่าง ๆ ทำได้ดี
    ทุกที่มีผู้ดูแลที่ตรวจสอบแพ็กเกจและรับผิดชอบดูแล
    Arch Linux ก็เช่นกัน
    ความไม่น่าเชื่อถือโดยเนื้อแท้ของ AUR ถูกระบุไว้อย่างชัดเจนเสมอใน Arch Wiki และในวัฒนธรรมรอบ ๆ มัน และแตกต่างจากตัวจัดการแพ็กเกจของภาษาโปรแกรมอย่าง npm หรือ pip
  • ถ้าไม่ใช้ AUR ก็ถือว่า Arch โอเค
    ถ้าจะใช้ AUR ก็ต้องตรวจสอบทุกอย่าง
    ดิสโทรส่วนใหญ่ก็โอเค และดิสโทรใหญ่ ๆ ก็มีประวัติด้านนี้ค่อนข้างดี
  • ดูเหมือนว่าใน ecosystem ของ Node จะมีอะไรบางอย่างที่ทำให้เปราะบางเป็นพิเศษ
    อาจเป็นเพราะวัฒนธรรม DRY ที่มากเกินไป หรืออาจมีเหตุผลอื่น
    เท่าที่ฉันเคยใช้มา ยังไม่เคยเจอฝันร้ายของ dependency tree ระดับใกล้เคียงกันเลย

• ใน AUR มี แพ็กเกจกำพร้า 15,000 รายการ
  เช้านี้ฉันเรียงตามความนิยม แล้วรับช่วงดูแล 3 รายการที่แทบไม่อัปเดตมาสร้างบิลด์
  ถ้าคุณกำลังใช้แพ็กเกจกำพร้าอยู่ อาจคุ้มที่จะพิจารณารับช่วงดูแลเองก่อนที่คนไม่หวังดีจะเข้ามายึดไป

• ฉันอาจจะคิดผิด แต่สถานการณ์ครั้งนี้ดูเหมือนเป็นสัญญาณของการที่ เดสก์ท็อป Linux ถูกนำไปใช้มากขึ้น

• ฉันไม่เคยมีความจำเป็นต้องใช้ AUR
  ถ้าต้องการแพ็กเกจที่ไม่มีในคลังทางการ ฉันก็จะ build เอง หรือถ้ามี binary release ก็จะดาวน์โหลดมา
  วิธีนี้ทำให้ไม่จำเป็นต้องใช้ root ตอน build และยังติดตั้งโปรแกรมแบบ local สำหรับผู้ใช้คนเดียวได้ ซึ่งจริง ๆ แล้วเหมาะกับการใช้งานเดสก์ท็อปส่วนใหญ่ด้วยซ้ำ
  อย่างน้อยก็ลด ความเป็นไปได้ของการสอดแทรกโค้ดอันตราย ลงไปได้อีกหนึ่งขั้น จากเส้นทาง นักพัฒนา → ผู้ใช้ ให้กลายเป็น นักพัฒนา → ผู้ดูแลแพ็กเกจ → ผู้ใช้

  • makepkg จะปฏิเสธอย่างจริงจังถ้ารันด้วย root
    มันจะไม่ทำงานด้วยสิทธิ์ root เว้นแต่จะฝืนอ้อมด้วยอะไรอย่าง env EUID=123 makepkg ...
    แต่ก็คงดีถ้า pacman รองรับการติดตั้งระดับผู้ใช้
    ตอนนี้ถ้าไม่ใช่ root มันจะปฏิเสธการติดตั้ง และก็พอจะอ้อมได้ด้วยการแมปตัวเองเป็น root ผ่าน user namespace

• ฉันเข้าใจได้ว่าครั้งนี้เป็น AUR
  ไม่ว่าจะเป็น AUR หรือไม่ก็ตาม อยากให้ช่วยแชร์ว่าตอนติดตั้งแพ็กเกจคุณผ่านขั้นตอนอะไรบ้าง และรับประกันได้อย่างไรว่าทั้งแพ็กเกจที่จะติดตั้งและ dependency ของมันไม่ใช่มัลแวร์
  เพราะถ้าติดตั้งแพ็กเกจแย่ ๆ ไปแล้ว มันดูเหมือนจะย้อนกลับได้ยากมากจริง ๆ