O npm libera publicação em estágios com aprovação humana antes do release

O npm, gerenciador de pacotes padrão do Node.js e hoje mantido pelo GitHub, tornou o staged publishing (publicação em estágios) disponível de forma geral. Segundo a InfoQ, o recurso adiciona uma etapa explícita de aprovação por um mantenedor humano antes de uma versão publicada ficar instalável para os consumidores.

Como funciona

Em vez de um publish direto que expõe a versão imediatamente, o tarball já construído é enviado para uma fila de estágio (stage queue), visível tanto no npmjs.com quanto na CLI. Um mantenedor humano precisa então passar por um desafio de autenticação de dois fatores (2FA) para liberar a versão.

Um detalhe importante para quem tem pipelines: o staging em si não exige 2FA e funciona com qualquer tipo de token, então pipelines de CI não interativos não são afetados. A prova de presença humana migra para a etapa de aprovação. O recurso exige o npm CLI 11.15.0 ou superior e Node 22.14.0 ou mais recente, e o pacote já precisa existir no registro.

O fluxo é um conjunto pequeno de subcomandos:

npm stage publish        # envia a versão para a fila de estágio
npm stage list           # lista versões aguardando aprovação
npm stage view <stage-id> # inspeciona o tarball em estágio
npm stage approve <stage-id> # promove ao registro, pede 2FA
npm stage reject <stage-id>  # descarta

O GitHub recomenda combinar o staging com trusted publishing via OIDC, onde uma configuração pode ser limitada apenas ao estágio, de modo que um npm publish direto daquele workflow seja rejeitado. Flags como --tag e --provenance se comportam como no npm publish normal.

Novas flags de permissão

A mesma release adiciona --allow-file, --allow-remote e --allow-directory ao lado do já existente --allow-git. Cada uma aceita all ou none e pode ser configurada no .npmrc ou no package.json. Segundo a fonte, --allow-git passará a ter none como padrão na v12.

O contexto: uma sequência de incidentes

O recurso surge após uma sequência dura de incidentes de cadeia de suprimentos, das ondas do worm Shai-Hulud a uma migração conturbada para longe dos tokens clássicos. O pesquisador de segurança Adnan Khan foi enfático em publicação no X, afirmando que todos que publicam no npm deveriam ativar o recurso hoje: publicar via CI com OIDC e aprovar o pacote antes de ir ao ar. "Shai-Hulud? Denied", escreveu.

O debate, porém, não é unânime. No Hacker News, o usuário weinzierl argumentou que, visto com realismo, o staging é um "band-aid" que a longo prazo pode até prejudicar esforços por infraestrutura mais segura. Outro comentarista rebateu: para o trusted publishing, não é paliativo, e sim uma melhoria significativa que "mata uma classe inteira de ataques de takeover de CI". Houve ainda quem questionasse a adoção, notando que o recurso só ajuda "se os mantenedores realmente usarem", e quem perguntasse se não deveria ser obrigatório por padrão.

Concorrentes já se moveram

O ecossistema reagiu rápido. O pnpm 11.3 adicionou pnpm stage com os mesmos subcomandos, o Yarn expõe yarn npm stage list, e o release-it passou a suportar a opção "stage": true. O pnpm também atrasa por padrão a instalação de releases muito novas, uma defesa complementar.

O que muda para quem publica pacotes no Brasil

Para devs e times brasileiros que mantêm pacotes open source ou publicam bibliotecas internas via npm, o staging oferece uma barreira concreta contra publicações comprometidas a partir da CI. Times que já usam trusted publishing por OIDC podem reaproveitar a configuração de bulk trusted publishing para migrar pacotes, atualizar a CI para a CLI mais nova e trocar o comando de publicação.

O GitHub afirma que os próximos passos incluem tornar os granular access tokens que burlam 2FA restritos apenas ao estágio, além de um campo allowScripts que transforma scripts de instalação em opt-in na v12.

Fonte: InfoQ