Perubahan kompatibilitas yang akan merusak pada npm v12

 (github.blog)
1 poin oleh GN⁺ 4 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Di npm v12, nilai default terkait keamanan untuk npm install akan berubah dari eksekusi·resolusi otomatis menjadi model izin eksplisit, dan perubahan ini bisa diperiksa lebih awal melalui peringatan di npm 11.16.0 atau yang lebih baru
  • Nilai default allowScripts akan berubah menjadi nonaktif, sehingga eksekusi skrip preinstall, install, postinstall dari dependensi yang tidak diizinkan secara eksplisit, node-gyp rebuild implisit, serta skrip prepare dari dependensi git·file·link akan diblokir
  • Gunakan npm approve-scripts --allow-scripts-pending untuk memeriksa paket yang akan diblokir, tentukan izin·blokir dengan npm approve-scripts dan npm deny-scripts, lalu commit allowlist yang dihasilkan ke package.json
  • Nilai default --allow-git akan berubah menjadi none, sehingga resolusi dependensi Git langsung maupun transitif yang tidak diizinkan secara eksplisit dengan --allow-git akan dihentikan
  • Menutup jalur eksekusi kode di mana .npmrc dari dependensi Git dapat menimpa executable Git bahkan saat menggunakan --ignore-scripts
  • Nilai default --allow-remote akan berubah menjadi none, sehingga resolusi dependensi URL jarak jauh seperti tarball https yang tidak diizinkan secara eksplisit dengan --allow-remote akan dihentikan
  • Nilai default --allow-file dan --allow-directory tidak berubah di npm v12
  • Prosedur persiapan adalah upgrade ke npm 11.16.0 atau yang lebih baru, jalankan instalasi biasa untuk meninjau peringatan, setujui hanya paket yang tepercaya, lalu setelah upgrade hanya skrip yang sudah disetujui yang akan terus dijalankan
  • Dokumentasi terkait: npm approve-scripts, npm deny-scripts, allow-scripts config

Bacaan terkait

1 komentar

 
GN⁺ 4 jam lalu
Opini di Hacker News

  • Entah bagaimana saya luput bahwa npm diakuisisi oleh GitHub, tapi tiba-tiba banyak hal mulai masuk akal
    Sulit membayangkan rumah yang lebih buruk untuk bagian ekosistem Node yang sepenting ini

  • skrip postinstall seharusnya sudah dihapus sejak lama, dan merupakan kanker pada paket NPM
    Terlalu sering saat mengambil sesuatu, postinstall yang sangat bersarang dan tidak terkendali dijalankan secara acak
    Saya tidak tahu siapa yang pernah menganggap ini ide bagus

    • Saya kurang paham inti kekhawatiran soal skrip post-install
      Biasanya Anda toh akan menjalankan kode dependensi yang dipaketkan itu pada suatu titik, dan umumnya dengan hak akses yang sama seperti proses instalasi
      Jadi skrip setup seperti ini, baik atau buruk, hanya memindahkan titik masuknya dari npm ke tempat import atau require terjadi
      Kecuali seluruh ekosistem pindah ke lingkungan sandbox seperti Deno, ini paling banter tampak seperti hambatan kecil. Mungkin memang itu rencananya
    • Sama sekali tidak boleh begitu, dan ada banyak kasus penggunaan yang valid
      Contoh yang langsung terlintas adalah https://www.npmjs.com/package/patch-package
      Semoga histeria saat ini tidak berujung pada keputusan sia-sia seperti ini

  • Rasanya hal ini sudah dibahas ratusan kali di internal NPM sejak diumumkan 10 tahun lalu
    Karena Shai Halud, sekarang ini sudah terlalu besar untuk diabaikan

    • Saya suka bahwa sejarah JavaScript pada dasarnya terasa seperti konsentrat pola pikir makanan pengembang
      “Nanti saya perbaiki” hampir selalu menjadi “sial, sekarang harus saya perbaiki”
    • Bagus, sekarang giliran Python berikutnya

  • Saya penasaran apakah versi Node LTS saat ini, kalau tidak salah 22, 24, 26, akan menaikkan npm bawaan ke v12 agar mendapat manfaat dari perbaikan keamanan ini
    Saat ini semuanya menyertakan npm v11

    • Di masa lalu memang pernah ada upgrade mayor npm dalam rilis minor Node
      Pada v18.19.0[1] dan v20.10.0[2], npm dinaikkan dari 9 ke 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
    • Karena ini perubahan default, ini bisa dilihat sebagai perubahan postur keamanan, tetapi perbaikan keamanannya sendiri sebenarnya sudah bisa diterapkan semua orang
      Seperti yang tertulis di artikel, cukup atur default yang sesuai
      Bagian terbaik dari perubahan ini adalah, dengan berubahnya default, paket-paket menyebalkan yang mengasumsikan pengaturan ini aktif saat developer baru sekadar menjalankan install akan langsung rusak
      Misalnya, ini bisa menghentikan kebiasaan yang mengharapkan skrip dapat dijalankan

  • Dari artikelnya tidak terlalu jelas, tetapi tampaknya allowlist skrip mendukung izin per paket, bukan konfigurasi global
    Ini sepertinya akan mempermudah pemeliharaan kebijakan tingkat organisasi yang hanya mengizinkan skrip untuk paket tertentu
    Saya penasaran apakah ada linter yang bisa dipakai untuk mencegah default tidak aman dalam konfigurasi package manager seperti ini

    • Bukannya grep saja cukup?

  • Saya penasaran apakah masih ada alasan untuk memakai Yarn
    Saya tidak tahu apakah Yarn juga telah menerapkan perlindungan untuk mencegah serangan supply chain
    Selama ini saya hanya tahu pnpm, jadi bagus kalau npm ikut menyusul

    • Tentu saja ada
      Rilis Yarn terbaru, 4.x, menjamin perilaku deterministik secara berlebihan, dan Anda bisa mengharapkan perilaku yang konsisten di seluruh tim
      Dari sisi fitur, ada banyak detail kecil, dan setelah terbiasa semuanya bergabung menjadi perbedaan besar
      Rilis mayor berikutnya juga akan terus mendorong ke arah yang sama, dengan performa yang lebih baik dan fitur-fitur yang selama ini belum bisa diimplementasikan karena bergantung pada peningkatan performa itu
      Sebagai catatan, saya adalah lead maintainer Yarn
    • Saya pernah bekerja pada proyek yang memakai Yarn sejak awal sampai v3, sangat lambat tapi tetap jalan
      Fitur perlindungan supply chain juga ada
      Pada akhirnya saya tidak tahan dan pindah ke pnpm, dan instalasi jadi jauh lebih cepat baik di CI maupun di mesin pengembangan lokal
      Dengan bantuan LLM, migrasinya memakan waktu sekitar satu hari
    • Salah satu pembeda adalah strategi instalasi opsional, yaitu menjalankan paket langsung dari arsip terkompresi tanpa mengekstraknya ke node_modules
      https://yarnpkg.com/features/pnp
      Ini cukup mirip dengan penggunaan .jar di Java alih-alih pohon direktori file .class
      Hanya saja agak hacky, dan dukungan editor serta tool berbeda-beda
      Karena jumlah file kecilnya jauh lebih sedikit, ini bisa jauh lebih cepat terutama jika terpaksa bekerja di Windows
      Arsipnya juga bisa dimasukkan ke repositori git, sehingga ketergantungan pada internet dan package registry bisa dihilangkan
    • Saya tidak tahu persis apa yang dilakukan NPM, tetapi Yarn jauh lebih cepat untuk instalasi dependensi daripada NPM
    • Orang-orang yang downvote komentar saya juga boleh menjawab pertanyaannya
      Saya benar-benar tidak tahu jawabannya

  • Saya tidak tahu npm dimiliki GitHub
    Itu menjelaskan banyak hal

    • NPM Is Joining GitHub - https://news.ycombinator.com/item?id=22594549 (16 Maret 2020, 571 komentar, 1829 poin) - https://github.blog/news-insights/company-news/npm-is-joinin...
      Sebagian terasa menarik dibaca setelah sekian waktu
      Komentar teratas berbunyi kurang lebih: “Microsoft tidak selalu melakukan semuanya dengan benar, tetapi akuisisi GitHub sejujurnya berjalan jauh lebih baik dari perkiraan. Alih-alih memaksakan kebijakan berpusat pada Microsoft ke GitHub, justru Microsoft yang lebih banyak mengadopsi hal-hal dari GitHub dari sudut pandang produk. GitHub masih beroperasi seperti perusahaan terpisah”
    • Perusahaan NPM nyaris bangkrut pada 2020
      Mereka mendapat pendanaan ventura tetapi tidak pernah menemukan model bisnis yang berkelanjutan
      GitHub mengakuisisinya untuk menyelamatkan ekosistem, dan akuisisi ini juga nyaris tidak memberi keuntungan besar bagi GitHub
    • Kebanyakan orang tahu ini, tetapi alasan yang benar-benar menjelaskan banyak hal adalah bahwa GitHub dimiliki Microsoft
      Dan Microsoft memindahkan GitHub ke Azure
    • Saya tahu itu dimiliki GitHub, tetapi ini pertama kalinya saya melihat catatan rilis langsung di blog GitHub, bukan blog npm

  • Saya penasaran apakah allowlist di package.json itu mengunci hingga versi paket, atau hanya nama paket saja

  • Menyenangkan bahwa default allowScripts dimatikan
    [melihat jam] Jadi ini berarti 18 bulan terlambat mengikuti pnpm?

    • Maven di Java tidak punya hal seperti itu, dan saya juga tidak pernah merasa itu perlu
      Sebenarnya ini untuk tujuan apa di dunia JavaScript?