Trusted Publishing do PyPI não deve ser visto como um sinal de confiança do pacote
(blog.yossarian.net)- A “confiança” de Trusted Publishing não significa que as pessoas podem confiar no pacote, mas sim a relação de autenticação de upload entre uma identidade de máquina externa, como CI/CD, e o índice de pacotes
- A implementação do PyPI funciona sobre uma federação OIDC e emite credenciais de publicação curtas e de escopo restrito no lugar de tokens de API de longa duração, reduzindo a exposição de credenciais duradouras e com permissões excessivas
- Depois que o PyPI lançou isso em 2023, a prática se espalhou para npm, RubyGems, crates.io, NuGet e outros, mas ainda permanecem a complexidade do modelo de dados, o tratamento específico por provedor OIDC e a possibilidade de comprometimento do CI/CD
- O PyPI não destaca o estado de Trusted Publishing com um check verde na página do projeto, mostrando-o apenas como metadado simples de Sim/Não nos detalhes do arquivo para reduzir o risco de ser confundido com um sinal de segurança
- Trusted Publishing e as attestations do PyPI apenas informam sobre autenticação de upload ou assinatura baseada em identidade de máquina; sem confiar separadamente nessa identidade, não é possível julgar a segurança ou a qualidade do pacote
O escopo de confiança tratado pelo Trusted Publishing
- Trusted Publishing não é um recurso que diz às pessoas para confiarem em um pacote, mas um método de autenticação voltado à confiança entre máquinas
- Enxergar o Trusted Publishing como uma questão de se humanos podem ou não confiar nele é confundir categorias
- O ponto central é estabelecer uma relação de confiança para autenticação de upload entre uma identidade de máquina externa, como um workflow de CI/CD, e a identidade do projeto no índice de pacotes
A estrutura do Trusted Publishing no PyPI
- “Trusted Publishing” é o termo usado pelo PyPI para descrever um método de autenticação sobre uma federação OpenID Connect
- O PyPI o lançou em 2023, e depois disso npm, RubyGems, crates.io, NuGet e outros também o adotaram
- O ponto de partida são dois problemas
- Tokens de API do índice, que são credenciais de longa duração, são difíceis de gerenciar com segurança, e os usuários têm dificuldade para definir privilégio mínimo e prazo de expiração, o que faz com que sejam frequentemente configurados com permissões excessivas
- Muitos usuários criam credenciais para colocá-las em plataformas de CI/CD, e essas plataformas também têm mecanismos para provar o controle de uma identidade de máquina específica por meio de OIDC
- O usuário registra uma vez no índice de pacotes uma identidade de máquina de CI/CD como Trusted Publisher, e quando o CI/CD apresenta um token de identidade, o índice o verifica e emite uma credencial de publicação curta e de escopo restrito
Vantagens e limitações que permanecem
- O modelo de credenciais curtas e com escopo próprio é avaliado como uma abordagem de grande sucesso para os usuários do PyPI
- Os usuários preferem uma forma em que não precisam gerenciar credenciais diretamente quando isso não é necessário
- Grandes projetos open source e empresas preferem a propriedade de que a permissão de publicação fique vinculada a uma identidade de origem, e não a um mantenedor individual
- Ainda assim, há complexidade estrutural no Trusted Publishing
- Os “pending publishers” do PyPI resolvem o problema de projetos que ainda não existem, mas tornam o modelo de dados mais complexo e são mais confusos para os usuários do que o Trusted Publishing comum
- Provedores OIDC podem colocar vários valores no conjunto de claims além de algumas claims comuns, então o índice precisa tratar separadamente os formatos específicos de cada provedor
- Por isso, identidades de máquina não são intercambiáveis entre diferentes IdPs OIDC, e esse é um dos motivos pelos quais o PyPI adiciona novos provedores de Trusted Publishing lentamente
- Se um workflow de CI/CD for comprometido, um invasor pode vazar credenciais de Trusted Publishing ou os tokens OIDC ID que servem de base para elas
- Isso é semelhante ao caso em que credenciais de longa duração estão no workflow, mas as credenciais de Trusted Publishing não carregam os mesmos riscos de escopo e duração
- O PyPI reduz o risco de comprometimento do CI/CD recusando a troca de tokens para identidades de máquina correspondentes a gatilhos facilmente abusáveis, como
pull_request_target
Por que isso não é um sinal de confiança do pacote
- Trusted Publishing é apenas um método de autenticação e não fornece informação sobre se um pacote é seguro, de alta qualidade ou vale a pena usar
- O PyPI é um índice público, então qualquer pessoa pode fazer upload, e qualquer pessoa também pode fazer upload usando Trusted Publisher
- Também é possível enviar malware ou código vulnerável com um Trusted Publisher
- Nesse aspecto, ele é igual ao token de API, outro método de autenticação de upload do PyPI
- Trusted Publishing não é obrigatório no PyPI e nunca poderá se tornar obrigatório
- Impor Trusted Publishing aos usuários é inviável do ponto de vista de engenharia e também não é desejável técnica nem socialmente
- Trusted Publishing será sempre opcional
Como a interface do PyPI reduz mal-entendidos
- O PyPI toma cuidado para que os usuários não confundam o estado de Trusted Publishing com um sinal de confiança do pacote
- Não há check verde indicando o estado de Trusted Publishing na página do projeto
- O check verde para estados controlados pelo usuário é usado apenas em links cuja origem o PyPI consegue comprovar como sendo a mesma do próprio pacote
- URLs verificadas apenas provam que, no momento da verificação, aquela URL estava sob o controle do proprietário do pacote no PyPI, e não significam segurança adicional da URL ou do projeto
- O estado de Trusted Publishing de um arquivo específico é mostrado nos detalhes do arquivo como um simples valor de Sim/Não
- A área de metadados do arquivo não é renderizada como se fosse uma informação importante para a decisão de confiança do usuário
- O blob JSON vindo do user agent do cliente de upload também não é renderizado de forma destacada
Distinção em relação às attestations
- Esse ponto é separado das attestations do PyPI
- As attestations também usam atualmente identidade de máquina via OIDC, mas não são um sinal de confiança
- Uma attestation é parecida com uma assinatura sobre uma identidade de máquina, mas como qualquer pessoa pode fazer upload no PyPI, qualquer pessoa também pode assinar com uma identidade de máquina sob seu controle
- Ter um Trusted Publisher não significa necessariamente que exista uma attestation, e ter uma attestation também não significa que o usuário final deva confiar em uma identidade específica
- O modelo de confiabilidade das attestations do PyPI também documenta esse ponto na documentação
1 comentários
Comentários no Lobste.rs
Bom texto. Trusted Publishing e atestação (attestation) oferecem garantias diferentes para modos de falha diferentes, e ambos também são coisas separadas do que a maioria dos usuários chama de confiança
O que tornou o Trusted Publishing possível foi que, nos últimos 15 anos, muitos projetos open source migraram de auto-hospedagem — como listas de e-mail, repositórios Git, rastreadores de bugs e servidores de build — para forjas centralizadas
Agora, conforme as desvantagens das forjas centralizadas ficam mais evidentes, projetos estão voltando a considerar a auto-hospedagem
Na década de 2010, a conveniência e os efeitos de rede social empurraram projetos para forjas centralizadas, mas agora há muito mais fatores que prendem os projetos, incluindo o Trusted Publishing
Desconfie da autoridade — promova a descentralização
— "The Hacker Ethics", Hackers: Heroes of the Computer Revolution (Steven Levy, 1984)
Há certa ironia em chamar autenticação federada de uma forma de aprisionamento
Mais ou menos na mesma época, cerca de 25 anos atrás, também existia a ASF, mas a ASF trazia muito ônus de governança. Antes disso havia o projeto GNU, que enfatizava mais a ideologia do software livre e se concentrava menos em um serviço sistemático de hospedagem de projetos. Isso porque o GNU existia antes de haver uma noção clara de quais serviços um projeto de software livre precisava
Projetos de software livre dos anos 1990 normalmente ficavam hospedados em serviços de tempo compartilhado de universidades ou no servidor em colocation de algum amigo. Exemplos incluem o PuTTY ou o Hyperreal.org, onde ficava o Apache httpd antes da ASF
Poucos projetos cresciam o bastante para justificar infraestrutura própria, e hospedagem barata também só se tornou disponível relativamente recentemente