O Python Packaging Authority liberou o pip 26.1 com duas mudancas que mexem direto no fluxo de quem instala pacote em CI. A primeira e o dependency cooldown, que bloqueia a instalacao de versoes recem-publicadas. A segunda e o suporte experimental a lockfile pylock.toml, formato da PEP 751 que ate entao so o uv sabia instalar.
O que e dependency cooldown
A ideia e simples: pacote acabado de publicar fica em quarentena pelo numero de dias que voce escolher. A flag e --uploaded-prior-to PXD, onde X e o numero de dias minimo desde o upload pra versao ser elegivel. Segundo a release, um cooldown de 7 dias teria evitado 8 dos 10 ataques de cadeia de suprimentos analisados — janela que da tempo de a comunidade detectar pacote envenenado antes que ele vire dependencia transitiva em milhares de pipelines.
O uso em CI e o caso obvio. Coloca --uploaded-prior-to P7D no comando de install e o pipeline rejeita silenciosamente qualquer versao publicada nos ultimos sete dias. Em desenvolvimento local, vale relaxar — o ponto da quarentena e proteger ambiente compartilhado.
Lockfile pylock.toml chega no pip
A PEP 751 padronizou o formato de lockfile pra Python ha um ano. Ate o pip 26.1, so o uv conseguia instalar a partir dele. Agora pip install -r pylock.toml funciona out of the box.
A equipe do pip rotula o recurso como experimental e se reserva o direito de modificar ou remover sem aviso. Na pratica, isso significa que vale testar em projeto novo, mas nao migrar pipeline de producao do uv ou poetry pra esse caminho ainda.
Pra projeto que ja usa uv, nada muda no dia a dia. Pra projeto que ainda usa pip freeze > requirements.txt, e a hora de comecar a olhar pra lockfile de verdade — sai do formato lossy do requirements.txt pra um lockfile com hashes e plataforma fixos.
Duas CVEs corrigidas
O release tambem fecha duas vulnerabilidades:
A CVE-2026-3219 corrige bug em que o pip confundia arquivos .tar.gz com zip, deixando atacante esconder codigo dentro de uma estrutura que o pip processava de forma diferente do esperado. A CVE-2026-6357 fecha uma execucao arbitraria de codigo disparada por imports diferidos durante o auto-check do pip — basicamente, o proprio pip executava codigo de um pacote enquanto checava se havia atualizacao.
Ambas estao na faixa que justifica atualizar imediatamente. pip install --upgrade pip resolve.
O contexto que torna isso urgente
A onda de ataques contra registry npm ao longo de 2025 e 2026 deixou claro que cadeia de suprimentos e o vetor preferido contra dev. Python nao escapou — o ecosistema PyPI viu campanhas de typosquatting e pacotes maliciosos publicados em sequencia. O cooldown nao resolve o problema, mas baixa a probabilidade de codigo malicioso entrar em pipeline antes da comunidade reagir.
A combinacao com lockfile da PEP 751 tambem fecha vetor: lockfile com hash trava versao exata, e o cooldown garante que a versao travada teve tempo de ser inspecionada.
Como avaliar isso na pratica
Pra time que ja se acostumou com supply chain como problema serio, o caminho e: adicionar --uploaded-prior-to P7D em pipeline de CI esta semana, considerar gerar pylock.toml com ferramentas que ja suportam o formato (uv, poetry), e revisar permissoes do pip em sistema. Pra time que ainda nao mexeu no assunto, comecar pela atualizacao pra fechar as duas CVEs e o minimo.
O que ainda nao esta claro: o ecossistema vai padronizar em torno de pylock.toml ou cada gerenciador vai manter o proprio formato? A resposta sai nos proximos meses.
Reportado originalmente por InfoQ em 2026-05-26.
