Những thay đổi phá vỡ tương thích sắp tới trong npm v12

 (github.blog)
1 điểm bởi GN⁺ 4 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Trong npm v12, giá trị mặc định liên quan đến bảo mật của npm install sẽ chuyển từ tự động chạy·phân giải sang cơ chế chỉ cho phép khi được chỉ định rõ, và có thể kiểm tra trước qua cảnh báo từ npm 11.16.0 trở lên
  • Giá trị mặc định của allowScripts sẽ chuyển sang tắt, chặn việc chạy các script preinstall, install, postinstall của các dependency chưa được cho phép rõ ràng, cũng như chặn node-gyp rebuild ngầm định và script prepare của các dependency dạng git·file·link
  • Có thể dùng npm approve-scripts --allow-scripts-pending để kiểm tra các package sẽ bị chặn, sau đó dùng npm approve-scripts và npm deny-scripts để quyết định cho phép·chặn, rồi commit allowlist được tạo vào package.json
  • Giá trị mặc định của --allow-git sẽ đổi thành none, ngừng phân giải các dependency Git trực tiếp·bắc cầu nếu không được cho phép rõ ràng bằng --allow-git
  • Chặn đường thực thi mã mà .npmrc của dependency Git có thể ghi đè tệp thực thi Git ngay cả khi đang dùng --ignore-scripts
  • Giá trị mặc định của --allow-remote sẽ đổi thành none, ngừng phân giải các dependency URL từ xa như tarball https nếu không được cho phép rõ ràng bằng --allow-remote
  • Giá trị mặc định của --allow-file và --allow-directory không thay đổi trong npm v12
  • Quy trình chuẩn bị là nâng cấp lên npm 11.16.0 trở lên, chạy cài đặt thông thường để xem lại cảnh báo, chỉ phê duyệt các package đáng tin cậy, và sau khi nâng cấp thì chỉ các script đã được phê duyệt mới tiếp tục chạy
  • Tài liệu liên quan: npm approve-scripts, npm deny-scripts, allow-scripts config

Bài viết liên quan

1 bình luận

 
GN⁺ 4 giờ trước
Ý kiến trên Hacker News

  • Không hiểu sao tôi lại bỏ lỡ việc npm được GitHub mua lại, nhưng tự nhiên giờ nhiều thứ bắt đầu trở nên dễ hiểu
    Khó mà nghĩ ra một mái nhà nào tệ hơn cho một phần quan trọng như thế này của hệ sinh thái Node

  • script postinstall lẽ ra phải bị loại bỏ từ lâu rồi, đúng là thứ ung thư của các gói NPM
    Có quá nhiều trường hợp chỉ cần tải cái gì đó về là một đống postinstall lồng sâu, không kiểm soát, chạy ngẫu nhiên
    Không hiểu ai từng nghĩ đây là ý hay

    • Tôi không thực sự hiểu mối lo cốt lõi về script post-install
      Thường thì dù sao bạn cũng sẽ chạy mã dependency đã đóng gói ở một thời điểm nào đó, và đa phần là với cùng quyền như lúc cài đặt
      Vậy thì các script cấu hình kiểu này, dù tốt hay xấu, chỉ cần dời điểm vào từ npm sang chỗ xảy ra import hoặc require là được
      Trừ khi cả hệ sinh thái chuyển sang môi trường sandbox kiểu Deno, thì cùng lắm nó chỉ như một chướng ngại nhỏ. Có thể đó chính là kế hoạch
    • Tuyệt đối không nên làm vậy, và có rất nhiều trường hợp dùng hợp lý
      Ví dụ hiện ra ngay trong đầu là https://www.npmjs.com/package/patch-package
      Hy vọng cơn cuồng loạn hiện tại không dẫn tới những quyết định vô ích kiểu này

  • Chuyện này chắc hẳn đã được thảo luận hàng trăm lần bên trong NPM kể từ khi được nêu ra công khai 10 năm trước
    Vì Shai Halud nên giờ nó đã quá lớn để tiếp tục phớt lờ

    • Tôi thích việc lịch sử của JavaScript về cơ bản giống như phiên bản cô đặc của tư duy kiểu dev
      “Chúng tôi sẽ sớm sửa” gần như lúc nào cũng thành “chết tiệt, giờ phải sửa rồi”
    • Tốt, giờ đến lượt của Python

  • Tôi tò mò không biết các bản Node LTS hiện tại, nếu nhớ không nhầm là 22, 24, 26, có dự định nâng npm đi kèm lên v12 để được hưởng bản sửa bảo mật này không
    Hiện tại tất cả đều đang kèm npm v11

    • Trước đây từng có nâng cấp major version của npm trong các bản phát hành Node giữa vòng đời
      Ở v18.19.0[1] và v20.10.0[2], npm đã được nâng từ 9 lên 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
    • Đây có thể xem là thay đổi tư thế bảo mật vì nó đổi mặc định, nhưng bản sửa bảo mật thì ai cũng đã áp dụng được rồi
      Chỉ cần đặt mặc định phù hợp như bài viết nói là xong
      Điểm hay nhất của thay đổi này là khi mặc định đổi đi, các gói phiền toái vốn ngầm giả định các thiết lập này được bật sẽ hỏng ngay khi dev mới chỉ việc chạy install
      Ví dụ, điều này có thể buộc mọi người ngừng thói quen trông chờ script sẽ được chạy

  • Chỉ đọc bài thì chưa rõ, nhưng có vẻ danh sách cho phép script hỗ trợ cấp quyền theo từng package chứ không phải cấu hình toàn cục
    Có lẽ sẽ dễ hơn để duy trì các quy tắc cấp tổ chức chỉ cho phép script ở một số package cụ thể
    Tôi tự hỏi có linter nào dùng để chặn các mặc định không an toàn kiểu này trong cấu hình package manager không

    • Chẳng phải grep là được sao?

  • Tôi tự hỏi giờ còn lý do gì để dùng Yarn nữa không
    Không biết Yarn có triển khai các biện pháp bảo vệ chống tấn công chuỗi cung ứng không
    Trước giờ tôi chỉ biết pnpm, nên việc npm bắt kịp cũng là điều tốt

    • Tất nhiên là có
      Bản Yarn mới nhất 4.x đảm bảo hành vi xác định gần như quá mức, và bạn có thể kỳ vọng hành vi nhất quán trên toàn bộ team
      Về tính năng thì có nhiều chi tiết nhỏ, nhưng khi đã quen thì gộp lại tạo khác biệt lớn
      Bản major tiếp theo cũng sẽ tiếp tục đẩy theo hướng đó với hiệu năng tốt hơn, cùng các tính năng trước giờ chưa thể triển khai vì phụ thuộc vào các cải tiến hiệu năng ấy
      Nhân tiện, tôi là maintainer chính của Yarn
    • Tôi từng làm ở một dự án dùng Yarn từ thời đầu đến v3, cực chậm nhưng chạy được
      Nó cũng có tính năng bảo vệ chuỗi cung ứng
      Cuối cùng chúng tôi hết chịu nổi và chuyển sang pnpm, việc cài đặt nhanh hơn rất nhiều cả trên CI lẫn máy dev cục bộ
      Với sự trợ giúp của LLM, việc migrate mất khoảng một ngày
    • Một điểm khác biệt là chiến lược cài đặt có thể chọn được: thay vì bung package ra node_modules, nó chạy trực tiếp từ archive nén
      https://yarnpkg.com/features/pnp
      Khá giống việc trong Java dùng .jar thay cho cây thư mục .class
      Tuy hơi hacky một chút, và hỗ trợ từ editor cùng công cụ thì không đồng đều
      Vì số lượng file nhỏ ít hơn rất nhiều, nên nếu buộc phải làm việc trên Windows thì nó có thể nhanh hơn đáng kể
      Bạn thậm chí có thể đưa các archive vào kho git, từ đó loại bỏ phụ thuộc vào Internet và package registry
    • Không rõ NPM đang làm gì, nhưng Yarn cài dependency nhanh hơn rất nhiều so với NPM
    • Những người downvote bình luận của tôi cũng có thể trả lời câu hỏi đi
      Tôi thực sự không biết câu trả lời

  • Tôi không biết npm thuộc sở hữu của GitHub
    Điều đó giải thích được nhiều chuyện

    • NPM Is Joining GitHub - https://news.ycombinator.com/item?id=22594549 (16 tháng 3 năm 2020, 571 bình luận, 1829 điểm) - https://github.blog/news-insights/company-news/npm-is-joinin...
      Một số ý đọc lại sau thời gian khá thú vị
      Bình luận đứng đầu là: “Microsoft không làm mọi thứ đúng, nhưng thành thật mà nói thương vụ mua GitHub diễn ra tốt hơn tôi tưởng rất nhiều. Thay vì ép GitHub theo chính sách xoay quanh Microsoft, Microsoft lại tiếp nhận nhiều thứ của GitHub hơn từ góc độ sản phẩm. GitHub vẫn vận hành như một công ty riêng biệt.”
    • Công ty NPM hồi năm 2020 gần như sắp phá sản
      Họ có vốn đầu tư mạo hiểm nhưng không tìm ra được mô hình kinh doanh bền vững
      GitHub mua lại để cứu hệ sinh thái, và thương vụ này cũng hầu như không mang lại lợi ích lớn nào cho GitHub
    • Hầu hết mọi người đều biết điều đó, nhưng lý do nó thật sự giải thích được nhiều chuyện là vì GitHub thuộc sở hữu của Microsoft
      Và Microsoft đã chuyển GitHub sang Azure
    • Tôi biết nó thuộc GitHub, nhưng đây là lần đầu tôi thấy ghi chú phát hành nằm ngay trên blog GitHub chứ không phải blog npm

  • Tôi tò mò không biết danh sách cho phép trong package.json có ghim tới cả phiên bản package hay chỉ ghim theo tên package

  • Mặc định allowScripts tắt như vậy thật tuyệt
    [nhìn đồng hồ] hóa ra chỉ mất 18 tháng để đuổi theo pnpm à?

    • Maven của Java không có thứ đó, và tôi cũng chưa bao giờ thấy cần
      Vậy bên JavaScript cái này dùng để làm gì?