Resumo

  • PyPI diz que remover um usuário do projeto não remove os Trusted Publishers que ele possa ter registrado.
  • Papel de colaborador, configuração CI, token temporário e procedência de arquivo são registros de escopo diferente.
  • Um desligamento verificável relaciona esses registros sem converter um deles em prova dos demais.

O desligamento costuma parecer encerrado quando uma conta some da lista do projeto. A orientação de segurança do Trusted Publishing do PyPI fixa uma ressalva importante: retirar um usuário não retira automaticamente os Trusted Publishers que ele registrou. Por isso, a revisão de todos eles faz parte do desligamento de mantenedores.

Não se trata de presumir incidente. A documentação não diz que todo ex-colaborador configurou um publicador, que uma configuração mantida é insegura ou que houve upload. Ela separa duas superfícies de controle. A remoção prova uma alteração de papel humano; não prova quais identidades CI continuam autorizadas a publicar.

Nos papéis de organização do PyPI, Maintainer pode enviar lançamentos e Owner pode administrar projeto e colaboradores. Trusted Publishing responde a outra questão: se uma configuração específica de serviço CI pode trocar uma identidade OpenID Connect por um token curto, limitado àquele projeto, para upload. A curta duração reduz a exposição de credencial; não liga automaticamente a configuração do publicador à remoção de uma pessoa.

Quatro afirmações exigem evidência própria: o colaborador foi removido; a rota de publicação foi revogada; não houve publicação por essa rota; um arquivo definido foi publicado por determinada identidade. A última pode ser apoiada por uma atestação de publicação e pela procedência no Integrity API. Mesmo assim, uma atestação registra o arquivo, não reconstitui toda a decisão de desligamento, não prova controle atual de um fluxo e não declara que o código é confiável. PyPI limita expressamente esse significado.

O problema administrativo é trocar um registro por outro. O ticket de retirada de conta é visível e costuma sobreviver. A lista de Trusted Publishers e as permissões CI podem estar em telas diferentes. No futuro, alguém encontra o ticket e supõe que ele também informa quais editores existiam, quem os avaliou, quais foram mantidos e que identidade apareceu em lançamentos posteriores.

O registro de junção proposto por Daniel Kade é deliberadamente restrito: projeto, alteração de papel, inventário datado de Trusted Publishers, restrições de identidade em nível seguro, revisor responsável e decisão de manter, mudar ou remover cada editor. A procedência de arquivos posteriores entra como observação distinta. Nenhuma chave, segredo ou detalhe operacional precisa ser publicado para que a transição seja auditável.

Também há resultados rotineiros. Talvez não exista nenhum editor vinculado ao desligamento. Talvez uma automação seja mantida, de modo revisado, sob outra responsabilidade. Talvez uma identidade substituta apareça na procedência de uma distribuição nova. O ponto é não deduzir esses desfechos de uma única alteração de colaborador.

Fontes

  1. PyPI — Modelo de segurança de Trusted Publishers
  2. PyPI — Publicação com Trusted Publisher
  3. PyPI — Papéis e entidades
  4. PyPI Publish Attestation v1
  5. PyPI — Modelo de segurança de atestações
  6. PyPI Integrity API