การเปลี่ยนแปลงที่อาจทำให้ความเข้ากันได้ขาดหายซึ่งจะมาใน npm v12

 (github.blog)
1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ใน npm v12 ค่าดีฟอลต์ด้านความปลอดภัย ของ npm install จะเปลี่ยนจากการรันและตีความอัตโนมัติไปเป็นรูปแบบที่ต้องอนุญาตอย่างชัดเจน และสามารถตรวจสอบล่วงหน้าได้ผ่านคำเตือนใน npm 11.16.0 ขึ้นไป
  • ค่าดีฟอลต์ของ allowScripts จะเปลี่ยนเป็นปิด ทำให้บล็อกการรันสคริปต์ preinstall, install, postinstall ของ dependency ที่ไม่ได้รับอนุญาตอย่างชัดเจน รวมถึงบล็อก node-gyp rebuild แบบโดยปริยาย และสคริปต์ prepare ของ dependency แบบ git·file·link
  • สามารถใช้ npm approve-scripts --allow-scripts-pending เพื่อตรวจสอบแพ็กเกจที่จะถูกบล็อก จากนั้นกำหนดการอนุญาตหรือบล็อกด้วย npm approve-scripts และ npm deny-scripts แล้ว commit allowlist ที่สร้างขึ้นไว้ใน package.json
  • ค่าดีฟอลต์ของ --allow-git จะเปลี่ยนเป็น none ทำให้หยุดการตีความ direct และ transitive Git dependency ที่ไม่ได้รับอนุญาตอย่างชัดเจนด้วย --allow-git
  • ปิดกั้นเส้นทางการรันโค้ดที่ .npmrc ของ Git dependency สามารถใช้เพื่อเขียนทับไฟล์ปฏิบัติการ Git ได้ แม้จะใช้ --ignore-scripts อยู่ก็ตาม
  • ค่าดีฟอลต์ของ --allow-remote จะเปลี่ยนเป็น none ทำให้หยุดการตีความ dependency จาก remote URL เช่น https tarball ที่ไม่ได้รับอนุญาตอย่างชัดเจนด้วย --allow-remote
  • ค่าดีฟอลต์ของ --allow-file และ --allow-directory จะไม่มีการเปลี่ยนแปลงใน npm v12
  • ขั้นตอนการเตรียมพร้อมคืออัปเกรดเป็น npm 11.16.0 ขึ้นไป แล้วรันการติดตั้งตามปกติเพื่อตรวจสอบคำเตือน อนุมัติเฉพาะแพ็กเกจที่เชื่อถือได้ และหลังอัปเกรดจะมีเพียงสคริปต์ที่ได้รับอนุมัติเท่านั้นที่ยังคงรันต่อไป
  • เอกสารที่เกี่ยวข้อง: npm approve-scripts, npm deny-scripts, allow-scripts config

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

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

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

  • ไม่รู้เลยว่าพลาดเรื่องที่ npm ถูก GitHub เข้าซื้อกิจการไปได้ยังไง แต่จู่ๆ หลายอย่างก็เริ่มเข้าใจขึ้นมา
    นึกแทบไม่ออกว่าจะมีบ้านไหนที่แย่กว่านี้สำหรับส่วนที่สำคัญขนาดนี้ของ ecosystem ของ Node

    • ดูเหมือนว่าจะเกิดขึ้นในปี 2020
      https://github.blog/news-insights/company-news/npm-is-joinin...
    • ต่อให้ก่อนถูกซื้อกิจการ มันก็แย่มากอยู่แล้ว
    • มันดูเหมือนการ ทำให้บริการแย่ลงและเพิ่มการควบคุม เพื่อวางตำแหน่งเชิงกลยุทธ์สำหรับแรงกดดันด้านรายได้ในอนาคต
      นี่คือ “embrace, extend, extinguish”
      https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

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

    • ผมไม่ค่อยเข้าใจแก่นของความกังวลเรื่องสคริปต์ post-install เท่าไร
      ปกติแล้วคุณก็ต้องรันโค้ด dependency ที่แพ็กมาอยู่ดีในสักจุดหนึ่ง และส่วนใหญ่ก็รันด้วยสิทธิ์เดียวกับขั้นตอนติดตั้ง
      งั้นสคริปต์ตั้งค่าแบบนี้ ต่อให้ดีหรือแย่ ก็แค่ย้ายจุดเริ่มจาก npm ไปอยู่ตรงที่เกิด import หรือ require
      ถ้าทั้ง ecosystem ไม่ได้ย้ายไปสู่ สภาพแวดล้อม sandbox แบบ Deno กันหมด มันก็ดูเป็นแค่สิ่งกีดขวางเล็กๆ เท่านั้น อาจจะเป็นแผนก็ได้
    • ไม่ควรทำแบบนั้นเด็ดขาด และมีกรณีใช้งานที่มีประโยชน์หลายอย่าง
      ตัวอย่างที่นึกออกทันทีคือ https://www.npmjs.com/package/patch-package
      หวังว่ากระแสตื่นตูมตอนนี้จะไม่จบลงด้วยการตัดสินใจไร้ประโยชน์แบบนี้

  • เรื่องนี้น่าจะถูก ถกกันภายใน NPM เป็นร้อยครั้ง ตั้งแต่ถูกเปิดเผยเมื่อ 10 ปีก่อน
    เพราะ Shai Halud ตอนนี้มันใหญ่เกินกว่าจะเมินได้แล้ว

    • ผมชอบที่ประวัติศาสตร์ของ JavaScript ดูเหมือนเป็นการกลั่น วิธีคิดแบบนักพัฒนา ออกมาอย่างเข้มข้น
      “เดี๋ยวค่อยแก้” แทบจะกลายเป็น “บ้าเอ๊ย ตอนนี้ต้องแก้แล้ว” เสมอ
    • ดีเลย ทีนี้ก็ถึงตา Python แล้ว

  • สงสัยว่า Node เวอร์ชัน LTS ปัจจุบัน เท่าที่จำได้คือ 22, 24, 26 จะอัปเกรด npm ที่ bundle มาเป็น v12 เพื่อให้ได้ประโยชน์จากการแก้ด้านความปลอดภัยนี้ไหม
    ตอนนี้ทุกตัวมากับ npm v11

    • ในอดีตเคยมี การอัปเกรด npm แบบเมเจอร์เวอร์ชัน ในรีลีสย่อยของ Node อยู่แล้ว
      ใน v18.19.0[1] และ v20.10.0[2] มีการอัปเกรด npm จาก 9 เป็น 10
      [1]: https://nodejs.org/en/blog/release/v18.19.0#npm-updated-to-v...
      [2]: https://nodejs.org/en/blog/release/v20.10.0
    • นี่อาจมองได้ว่าเป็น การเปลี่ยนแปลงด้าน security posture เพราะเป็นการเปลี่ยนค่าดีฟอลต์ แต่ตัวการแก้ปัญหาความปลอดภัยเอง ทุกคนก็ใช้ได้อยู่แล้ว
      ก็แค่ตั้งค่าดีฟอลต์ให้เหมาะสมตามที่บทความบอก
      ข้อดีสุดของการเปลี่ยนนี้คือ เมื่อค่าดีฟอลต์เปลี่ยน นักพัฒนาใหม่ๆ จะเห็นทันทีว่าแพ็กเกจที่น่ารำคาญซึ่งตั้งสมมติฐานว่าแค่รัน install แล้วการตั้งค่านี้จะเปิดอยู่ กลับพังทันที
      เช่น อาจช่วยหยุดธรรมเนียมที่คาดหวังว่าสคริปต์จะต้องรันได้

  • จากบทความยังไม่ชัดเจน แต่ดูเหมือนว่า allowlist ของสคริปต์จะรองรับ การอนุญาตเป็นรายแพ็กเกจ ไม่ใช่การตั้งค่าระดับ global
    น่าจะทำให้รักษานโยบายระดับองค์กรที่อนุญาตสคริปต์เฉพาะบางแพ็กเกจได้ง่ายขึ้น
    สงสัยว่ามี linter ที่ใช้บล็อกค่าดีฟอลต์ไม่ปลอดภัยในคอนฟิกของ package manager แบบนี้ได้ไหม

    • grep ก็พอไม่ใช่เหรอ?

  • สงสัยว่ายังมี เหตุผลให้ใช้ Yarn อยู่ไหม
    ไม่รู้ว่า Yarn เองก็ทำกลไกป้องกัน supply chain attack ไว้หรือเปล่า
    ก่อนหน้านี้ผมรู้จักแค่ pnpm แต่ก็ดีที่ npm ตามมาทัน

    • มีอยู่แล้วแน่นอน
      Yarn รีลีสล่าสุด 4.x รับประกัน พฤติกรรมแบบกำหนดได้แน่นอน มากเสียจนแทบเกินไป และคุณคาดหวังพฤติกรรมที่สม่ำเสมอได้ทั้งทีม
      ในแง่ฟีเจอร์มีรายละเอียดเล็กๆ เยอะมาก ซึ่งพอคุ้นแล้วมันรวมกันจนเห็นความต่างชัด
      รีลีสเมเจอร์ถัดไปก็จะเดินแนวทางเดิมต่อ ทั้งประสิทธิภาพที่ดีกว่า และฟีเจอร์ที่ก่อนหน้านี้ทำไม่ได้เพราะต้องพึ่งการปรับปรุงด้านประสิทธิภาพนั้น
      เพื่อความโปร่งใส ผมคือ maintainer หลักของ Yarn
    • ผมเคยทำงานกับโปรเจกต์ที่ใช้ Yarn มาตั้งแต่ช่วงแรกจนถึง v3 ซึ่ง ช้ามากแต่ก็ใช้ได้
      มันก็มีฟีเจอร์ป้องกัน supply chain ด้วย
      สุดท้ายทนไม่ไหวเลยย้ายไป pnpm แล้วการติดตั้งเร็วขึ้นมากทั้งใน CI และบนเครื่องพัฒนาโลคัล
      ใช้ความช่วยเหลือจาก LLM แล้วใช้เวลาประมาณวันหนึ่งในการย้าย
    • จุดต่างอย่างหนึ่งคือกลยุทธ์การติดตั้งที่เลือกได้ โดยไม่แตกแพ็กเกจลง node_modules แต่ รันตรงจากไฟล์บีบอัด archive เลย
      https://yarnpkg.com/features/pnp
      มันค่อนข้างคล้ายกับการใช้ .jar ใน Java แทน directory tree ของไฟล์ .class
      เพียงแต่มันออกจะแฮ็กๆ หน่อย และการรองรับจาก editor กับเครื่องมือต่างๆ ก็ไม่สม่ำเสมอ
      เพราะจำนวนไฟล์ย่อยน้อยกว่ามาก มันเลยอาจเร็วกว่าโดยเฉพาะถ้าคุณจำเป็นต้องทำงานบน Windows
      คุณยังเอา archive เข้า git repository ได้ด้วย จึงตัดการพึ่งพาอินเทอร์เน็ตและ package registry ออกไปได้
    • ไม่รู้ว่า NPM ทำอะไรอยู่บ้าง แต่ Yarn ติดตั้ง dependency ได้เร็วกว่า NPM มาก
    • คนที่กดโหวตลบคอมเมนต์ผม จะตอบคำถามก็ได้นะ
      ผมไม่รู้คำตอบจริงๆ

  • ไม่เคยรู้มาก่อนว่า npm เป็นของ GitHub
    แบบนี้หลายอย่างก็อธิบายได้เลย

    • NPM Is Joining GitHub - https://news.ycombinator.com/item?id=22594549 (16 มีนาคม 2020, 571 ความเห็น, 1829 คะแนน) - https://github.blog/news-insights/company-news/npm-is-joinin...
      บางส่วนพอกลับมาอ่านตอนนี้ก็น่าสนใจดี
      คอมเมนต์บนสุดตอนนั้นคือ “Microsoft ไม่ได้ทำทุกอย่างได้ดีหมด แต่พูดตามตรง การเข้าซื้อ GitHub เป็นไปได้ดีกว่าที่คาดไว้มาก แทนที่จะบังคับนโยบายแบบ Microsoft-centric กับ GitHub กลับกลายเป็นว่า Microsoft รับเอาหลายอย่างของ GitHub ไปใช้ในมุมมองผลิตภัณฑ์มากกว่า GitHub ยังดำเนินงานเหมือนเป็นบริษัทแยกอยู่”
    • บริษัท NPM ตอนปี 2020 เกือบจะล้มละลายอยู่แล้ว
      ได้เงินลงทุนแบบ venture มาก็จริง แต่หาธุรกิจที่ยั่งยืนไม่เจอ
      GitHub เข้าซื้อเพื่อช่วยชีวิต ecosystem และดีลนี้ก็แทบไม่ได้สร้างประโยชน์ก้อนใหญ่ให้ GitHub เท่าไร
    • คนส่วนใหญ่รู้เรื่องนี้อยู่แล้ว แต่สิ่งที่อธิบายอะไรได้จริงๆ มากคือ GitHub เป็นของ Microsoft
      และ Microsoft ก็ย้าย GitHub ไปไว้บน Azure
    • ผมรู้ว่าเป็นของ GitHub อยู่แล้ว แต่ครั้งนี้เป็นครั้งแรกที่ได้เห็น release note อยู่บน บล็อกของ GitHub โดยตรง ไม่ใช่บล็อกของ npm

  • สงสัยว่า allowlist ใน package.json นี่ ล็อกถึงเวอร์ชันของแพ็กเกจ ด้วยไหม หรือแค่ล็อกชื่อแพ็กเกจอย่างเดียว

  • ดีเลยที่ allowScripts ปิดเป็นค่าดีฟอลต์
    [ดูนาฬิกา] แปลว่า npm ใช้เวลา 18 เดือน กว่าจะตาม pnpm ทันงั้นเหรอ?

    • Maven ของ Java ไม่มีอะไรแบบนี้ และผมก็ไม่เคยรู้สึกว่าจำเป็น
      ฝั่ง JavaScript เขาทำสิ่งนี้ไปเพื่ออะไร?