npm v12 için yaklaşan uyumluluğu bozan değişiklikler

 (github.blog)
1 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • npm v12'de npm install için güvenlikle ilgili varsayılanlar, otomatik çalıştırma/çözümlemeden açık izin modeline geçiyor; bunu npm 11.16.0 ve sonrasında uyarılarla önceden kontrol etmek mümkün
  • allowScripts varsayılanı kapalı olacak; böylece açıkça izin verilmeyen bağımlılıkların preinstall, install, postinstall betikleri ile örtük node-gyp rebuild ve git·file·link bağımlılıklarının prepare betiklerinin çalıştırılması engellenecek
  • npm approve-scripts --allow-scripts-pending ile engellenecek paketleri kontrol edip, npm approve-scripts ve npm deny-scripts ile izin/engel kararını verdikten sonra oluşturulan allowlist'i package.json içine commit etmek gerekiyor
  • --allow-git varsayılanı none olarak değişecek; --allow-git ile açıkça izin verilmeyen doğrudan ve dolaylı Git bağımlılıklarının çözümlemesi durdurulacak
  • Git bağımlılıklarının .npmrc dosyasının, --ignore-scripts kullanılırken bile Git çalıştırılabilir dosyasını override ederek kod çalıştırabildiği yol kapatılacak
  • --allow-remote varsayılanı none olarak değişecek; --allow-remote ile açıkça izin verilmeyen https tarball gibi uzak URL bağımlılıklarının çözümlemesi durdurulacak
  • npm v12'de --allow-file ve --allow-directory varsayılanlarında değişiklik yok
  • Hazırlık süreci olarak npm 11.16.0 veya üstüne yükseltip normal kurulum çalıştırarak uyarıları gözden geçirmek, yalnızca güvenilen paketleri onaylamak ve yükseltmeden sonra sadece onaylanmış betiklerin çalışmaya devam etmesini sağlamak öneriliyor
  • İlgili belgeler: npm approve-scripts, npm deny-scripts, allow-scripts config

İlgili okumalar

1 yorum

 
GN⁺ 4 시간 전
Hacker News yorumları

  • npm'in GitHub tarafından satın alındığını nasıl kaçırdım bilmiyorum ama birden birçok şey anlam kazanmaya başladı
    Node ekosisteminin bu kadar önemli bir parçası için bundan daha kötü bir yuva düşünmek zor

  • postinstall script'leri çoktan kaldırılmış olmalıydı; NPM paketlerinin kanseri gibiler
    Bir şey indirirken derinlere gömülü, kontrolsüz postinstall'ların rastgele çalıştırılması çok sık oluyor
    Bir noktada bunun iyi bir fikir olduğunu kim düşündü bilmiyorum

    • post-install script'lerine yönelik kaygının özünü pek anlayamıyorum
      Normalde paketlenmiş bağımlılık kodunu zaten bir noktada çalıştırıyorsunuz ve çoğu durumda kurulum süreciyle aynı yetkilerle çalışıyor
      O zaman bu tür kurulum script'leri, iyi ya da kötü, giriş noktasını npm'den import ya da require çağrısının olduğu yere taşımış olur
      Tüm ekosistem Deno benzeri sandbox ortamlarına geçmedikçe, en fazla küçük bir engel gibi görünüyor. Belki plan da budur
    • Kesinlikle öyle yapılmamalı ve birçok geçerli kullanım örneği var
      Aklıma ilk gelen örnek https://www.npmjs.com/package/patch-package
      Umarım şu anki histeri bu tür boş kararlarla sonuçlanmaz

  • Bu konu ilk kez 10 yıl önce gündeme geldiğinden beri NPM içinde yüzlerce kez tartışılmıştır diye tahmin ediyorum
    Shai Halud yüzünden artık görmezden gelinemeyecek kadar büyüdü

    • JavaScript'in tarihi neredeyse geliştirici usulü düşünme biçiminin damıtılmış hali gibi, hoşuma gidiyor
      “Birazdan düzeltiriz” neredeyse her zaman “Lanet olsun, şimdi düzeltmemiz gerekiyor”a dönüşüyor
    • Güzel, sırada Python var

  • Mevcut LTS Node sürümlerinin, yanlış hatırlamıyorsam 22, 24, 26'nın, bu güvenlik düzeltmesinden yararlanmak için birlikte gelen npm'i v12'ye yükseltmeyi planlayıp planlamadığını merak ediyorum
    Şu anda hepsi npm v11 içeriyor

    • Geçmişte Node'nun ara sürümlerinde npm majör sürüm yükseltmeleri olmuştu
      v18.19.0[1] ve v20.10.0[2] ile npm 9'dan 10'a geçildi
      [1]: https://nodejs.org/en/blog/release/v18.19.0#npm-updated-to-v...
      [2]: https://nodejs.org/en/blog/release/v20.10.0
    • Varsayılan değişikliği olduğu için bunu güvenlik duruşunda bir değişim olarak görebilirsiniz ama güvenlik düzeltmesinin kendisi zaten herkesin bugün uygulayabileceği bir şey
      Yazıda dendiği gibi uygun varsayılanları ayarlamak yeterli
      Bu değişikliğin en iyi yanı, varsayılanlar değişince yeni geliştiricilerin sadece install çalıştırdıklarında bu ayarların açık olduğunu varsayan sinir bozucu paketlerin hemen bozulduğunu görecek olmaları
      Örneğin script'lerin çalışabilir olmasını bekleyen alışkanlığın sona ermesine yardımcı olabilir

  • Yazıdan tam net değil ama script izin listesinin genel bir ayar değil, paket bazında izin vermeyi desteklediği anlaşılıyor
    Yalnızca belirli paketler için script'lere izin veren organizasyon düzeyi kuralları sürdürmek daha kolay olabilir
    Paket yöneticisi ayarlarında bu şekilde güvensiz varsayılanları engellemek için kullanılabilecek bir linter olup olmadığını merak ediyorum

    • grep yetmez mi?

  • Hâlâ Yarn kullanmak için bir neden olup olmadığını merak ediyorum
    Yarn'ın da tedarik zinciri saldırılarını önlemeye yönelik korumalar uygulayıp uygulamadığını bilmiyorum
    Şimdiye kadar sadece pnpm'i biliyordum; npm'in de yetişmesi güzel

    • Elbette var
      En yeni Yarn sürümü olan 4.x, neredeyse aşırıya kaçacak kadar deterministik davranış sağlıyor ve ekip genelinde tutarlı sonuçlar bekleyebiliyorsunuz
      Özellik tarafında küçük gibi görünen birçok ayrıntı var ve alışınca birleşip büyük fark yaratıyorlar
      Bir sonraki majör sürüm de daha iyi performans ve bu performans iyileştirmelerine dayanarak şimdiye kadar uygulanamayan özelliklerle aynı yönde ilerleyecek
      Bu arada Yarn'ın baş bakımcısıyım
    • İlk günlerinden v3'e kadar Yarn kullanan bir projede çalıştım; aşırı yavaş ama çalışıyor
      Tedarik zinciri koruma özellikleri de var
      Sonunda dayanamadık ve pnpm'e geçtik; hem CI'da hem yerel geliştirme makinelerinde kurulumlar çok daha hızlı oldu
      LLM yardımıyla migrasyon yaklaşık bir gün sürdü
    • Fark yaratan yönlerden biri seçilebilir kurulum stratejisi; paketleri node_modules içine açmak yerine sıkıştırılmış arşivlerden doğrudan çalıştırabiliyor
      https://yarnpkg.com/features/pnp
      Java'da .class dosya dizin ağacı yerine .jar kullanmaya epey benziyor
      Yine de biraz hacky ve editörlerle araç desteği tutarsız
      Küçük dosya sayısı çok daha az olduğu için, mecburen Windows'ta çalışıyorsanız özellikle daha hızlı olabilir
      Arşivleri git deposuna da koyabiliyorsunuz; böylece internete ve paket kayıtlarına bağımlılığı ortadan kaldırabiliyorsunuz
    • NPM'in ne yaptığını bilmiyorum ama Yarn, NPM'den bağımlılık kurulumunda çok daha hızlı
    • Yorumu­ma eksi oy verenler soruya cevap da verebilir
      Gerçekten bilmiyorum

  • npm'in GitHub'a ait olduğunu bilmiyordum
    Bu da birçok şeyi açıklıyor

    • NPM Is Joining GitHub - https://news.ycombinator.com/item?id=22594549 (16 Mart 2020, 571 yorum, 1829 puan) - https://github.blog/news-insights/company-news/npm-is-joinin...
      Bazı kısımlar zaman geçtikten sonra ilginç okunuyor
      En üstteki yorum şuydu: “Microsoft her şeyi doğru yapmıyor ama GitHub satın alımı açıkçası beklediğimden çok daha iyi gitti. Microsoft merkezli politikaları GitHub'a dayatmak yerine Microsoft, ürün açısından GitHub'ın yaptıklarını daha çok benimsedi. GitHub hâlâ ayrı bir şirket gibi işletiliyor.”
    • NPM şirketi 2020'de neredeyse batmak üzereydi
      Girişim sermayesi almıştı ama sürdürülebilir bir iş modeli bulamamıştı
      GitHub ekosistemi kurtarmak için satın aldı ve bu satın almanın GitHub'a da pek somut bir faydası olmadı
    • Çoğu kişi bunu biliyor ama gerçekten birçok şeyi açıklamasının sebebi GitHub'ın Microsoft'a ait olması
      Ve Microsoft, GitHub'ı Azure'a taşıdı
    • GitHub'a ait olduğunu biliyordum ama npm blogu yerine doğrudan GitHub blogundaki sürüm notlarını ilk kez görüyorum

  • package.json içindeki izin listesinin paket sürümünü de sabitleyip sabitlemediğini, yoksa yalnızca paket adını mı sabitlediğini merak ediyorum

  • allowScripts varsayılanının kapalı olması güzel
    [Saate bakar] pnpm'i takip etmeleri sadece 18 ay mı sürdü?

    • Java'nın Maven'ında böyle bir şey yoktu ve buna ihtiyaç duyduğumu da hiç hissetmedim
      JavaScript tarafında bunun amacı ne?