Mudanças incompatíveis planejadas no npm v12

 (github.blog)
1 pontos por GN⁺ 4 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • No npm v12, os padrões relacionados à segurança do npm install passarão de execução/interpretação automática para um modelo de permissão explícita, com verificação prévia por meio de avisos disponível no npm 11.16.0 ou superior
  • O padrão de allowScripts passará a ser desativado, bloqueando a execução dos scripts preinstall, install e postinstall de dependências que não forem explicitamente permitidas, assim como o node-gyp rebuild implícito e a execução do script prepare de dependências git, file e link
  • Com npm approve-scripts --allow-scripts-pending, é possível verificar quais pacotes serão bloqueados; depois, use npm approve-scripts e npm deny-scripts para definir o que será permitido ou bloqueado, e faça commit da allowlist gerada no package.json
  • O padrão de --allow-git mudará para none, interrompendo a resolução de dependências Git diretas e transitivas que não forem explicitamente permitidas com --allow-git
  • Bloqueio do caminho de execução de código em que o .npmrc de dependências Git podia sobrescrever o executável Git mesmo ao usar --ignore-scripts
  • O padrão de --allow-remote mudará para none, interrompendo a resolução de dependências por URL remota, como tarballs via https, que não forem explicitamente permitidas com --allow-remote
  • Os padrões de --allow-file e --allow-directory não terão mudanças no npm v12
  • O procedimento de preparação é atualizar para o npm 11.16.0 ou superior, executar uma instalação normal para revisar os avisos e aprovar apenas os pacotes confiáveis; depois da atualização, apenas os scripts aprovados continuarão sendo executados
  • Documentação relacionada: npm approve-scripts, npm deny-scripts, allow-scripts config

Leituras relacionadas

1 comentários

 
GN⁺ 4 시간 전
Comentários do Hacker News

  • Não sei como deixei passar que o npm foi adquirido pelo GitHub, mas de repente muita coisa começou a fazer sentido
    É difícil pensar em um lugar pior para abrigar uma parte tão importante do ecossistema Node

  • Scripts de postinstall já deveriam ter sido removidos há muito tempo e são um câncer nos pacotes NPM
    Tem postinstalls profundamente aninhados e sem controle demais sendo executados aleatoriamente quando você baixa alguma coisa
    Não sei quem em algum momento achou que isso era uma boa ideia

    • Não acho que entendo muito bem a essência da preocupação com scripts de post-install
      Normalmente você vai acabar executando o código de dependência empacotado de qualquer forma em algum momento, e em geral com os mesmos privilégios do processo de instalação
      Então esses scripts de configuração, sejam bons ou ruins, podem simplesmente mover seu ponto de entrada do npm para onde acontece o import ou require
      A menos que todo o ecossistema migre para um ambiente sandboxed como o Deno, isso parece no máximo um pequeno obstáculo. Embora esse possa ser o plano
    • Isso absolutamente não deveria acontecer, e há muitos casos de uso válidos
      Um exemplo que me vem à cabeça imediatamente é https://www.npmjs.com/package/patch-package
      Espero que a histeria atual não leve a decisões inúteis desse tipo

  • Isso provavelmente foi discutido centenas de vezes dentro do NPM desde que veio a público 10 anos atrás
    Por causa de Shai Halud, agora ficou grande demais para ignorar

    • Gosto de como a história do JavaScript basicamente parece uma destilação de um modo de pensar de desenvolvedor
      “A gente corrige depois” quase sempre vira “droga, agora a gente tem que corrigir”
    • Ótimo, agora é a vez do Python

  • Fico curioso se as versões LTS atuais do Node, se bem me lembro 22, 24, 26, vão atualizar o npm empacotado para o v12 para receber esse ajuste de segurança
    No momento todas incluem o npm v11

    • Já houve upgrade de versão major do npm em releases intermediárias do Node no passado
      O npm foi de 9 para 10 no v18.19.0[1] e no v20.10.0[2]
      [1]: https://nodejs.org/en/blog/release/v18.19.0#npm-updated-to-v...
      [2]: https://nodejs.org/en/blog/release/v20.10.0
    • Como é uma mudança de padrão, dá para ver como uma mudança de postura de segurança, mas o ajuste de segurança em si todos já podem aplicar
      Como o texto diz, basta configurar os padrões adequados
      A melhor parte dessa mudança é que, com o padrão alterado, pacotes irritantes que assumem que essas configurações estarão ativas quando novos desenvolvedores simplesmente rodarem install vão quebrar imediatamente
      Isso pode fazer com que parem com a prática de presumir que scripts podem ser executados

  • Pelo texto não fica claro, mas parece que a lista de permissões de scripts oferece suporte a permissão por pacote, e não só uma configuração global
    Deve ficar mais fácil manter políticas organizacionais que permitam scripts só para pacotes específicos
    Fico pensando se existe algum linter que possa ser usado para bloquear padrões inseguros nas configurações do gerenciador de pacotes desse jeito

    • grep não resolve?

  • Fico me perguntando se ainda existe algum motivo para usar Yarn
    Não sei se o Yarn também implementou proteções para impedir ataques à cadeia de suprimentos
    Até agora eu só conhecia o pnpm, então é bom ver o npm correndo atrás

    • Claro que existe
      A release 4.x mais recente do Yarn garante um comportamento determinístico quase ao ponto do exagero, e você pode esperar um comportamento consistente em toda a equipe
      Em termos de recursos, há muitos pequenos detalhes que, quando você se acostuma, acabam fazendo bastante diferença
      A próxima major também deve continuar nessa mesma direção, com desempenho melhor e recursos que até agora não dava para implementar sem depender desses ganhos de performance
      Para referência, sou o maintainer principal do Yarn
    • Trabalhei em um projeto que usava Yarn desde o começo até a v3, e é absurdamente lento, mas funciona
      Também tem recursos de proteção da cadeia de suprimentos
      No fim não aguentei e migrei para pnpm, e as instalações ficaram muito mais rápidas tanto no CI quanto nas máquinas locais de desenvolvimento
      Levei cerca de um dia para fazer a migração com ajuda de um LLM
    • Um dos diferenciais é a estratégia de instalação opcional, em que os pacotes não são extraídos em node_modules, mas executados diretamente de arquivos compactados
      https://yarnpkg.com/features/pnp
      É bem parecido com usar .jar em Java em vez de uma árvore de diretórios com arquivos .class
      Mas é um pouco gambiarra, e o suporte de editores e ferramentas varia bastante
      Como há muito menos arquivos pequenos, pode ser especialmente mais rápido se você for obrigado a trabalhar no Windows
      Também dá para colocar os arquivos no repositório git, eliminando a dependência de internet e de registros de pacotes
    • Não sei o que o NPM está fazendo, mas o Yarn é muito mais rápido para instalar dependências do que o NPM
    • Quem está dando downvote no meu comentário também pode responder à pergunta
      Eu realmente não sei a resposta

  • Eu não sabia que o npm era do GitHub
    Isso explica várias coisas

    • NPM Is Joining GitHub - https://news.ycombinator.com/item?id=22594549 (16 de março de 2020, 571 comentários, 1829 pontos) - https://github.blog/news-insights/company-news/npm-is-joinin...
      Algumas partes ficam interessantes de reler com o passar do tempo
      O comentário mais votado dizia algo como: “A Microsoft não acerta tudo, mas a aquisição do GitHub honestamente foi muito melhor do que eu esperava. Em vez de forçar políticas centradas na Microsoft no GitHub, a Microsoft acabou adotando mais coisas do GitHub na perspectiva de produto. O GitHub ainda opera como se fosse uma empresa separada”
    • A empresa NPM estava quase falindo em 2020
      Tinha recebido investimento de venture capital, mas não conseguiu encontrar um modelo de negócios sustentável
      O GitHub a adquiriu para salvar o ecossistema, e essa aquisição também quase não trouxe grande benefício para o GitHub
    • A maioria sabe disso, mas o que realmente explica muita coisa é que o GitHub pertence à Microsoft
      E a Microsoft moveu o GitHub para o Azure
    • Eu sabia que era do GitHub, mas foi a primeira vez que vi as notas de release diretamente no blog do GitHub, e não no blog do npm

  • Fico curioso se a lista de permissões no package.json fixa também a versão do pacote, ou se fixa só o nome do pacote

  • Bom ver que o padrão de allowScripts fica desativado
    [olha para o relógio] Só uns 18 meses atrás do pnpm, então?

    • O Maven do Java não tinha isso, e nunca senti que precisasse
      Para que isso serve no mundo JavaScript?