Trusted Publishing não deve ser visto como um sinal de confiança do pacote

• A “confiança” de Trusted Publishing não significa que humanos 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 um índice de pacotes
• A implementação do PyPI funciona sobre federação OIDC e emite credenciais de publicação curtas e de escopo limitado em vez de tokens de API de longo prazo, reduzindo a exposição de credenciais duradouras e com privilégios excessivos
• Depois de ser lançado pelo PyPI em 2023, o modelo se espalhou para npm, RubyGems, crates.io, NuGet e outros, mas continuam existindo 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 Yes/No nos detalhes do arquivo para reduzir a chance de ser interpretado como 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, e não permitem julgar a segurança ou a qualidade do pacote sem antes confiar separadamente nessa identidade

---

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 que lida com confiança entre máquinas
• Ver Trusted Publishing como uma questão de o ser humano poder ou não confiar nele é um enquadramento incorreto
• 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 de Trusted Publishing no PyPI

• “Trusted Publishing” é o termo que o PyPI usa para descrever um método de autenticação sobre a federação OpenID Connect
• O PyPI lançou isso em 2023 e, depois, npm, RubyGems, crates.io e NuGet também adotaram
• O ponto de partida são dois problemas
  • Tokens de API do índice, que são credenciais de longo prazo, 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, então frequentemente acabam 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 via 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 limitado

Vantagens e limitações que permanecem

• O modelo de credenciais curtas e com escopo próprio é avaliado como uma abordagem de grande sucesso para 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 característica de que a permissão de publicação fica vinculada à identidade da fonte, e não a um mantenedor individual
• Ainda há complexidade estrutural no Trusted Publishing
  • Os “pending publishers” do PyPI resolvem o problema de projetos ainda inexistentes, mas tornam o modelo de dados mais complexo e são mais confusos para o usuário do que o Trusted Publishing comum
  • Provedores OIDC podem colocar vários valores diferentes no conjunto de claims além de algumas claims comuns, então o índice precisa tratar separadamente o formato específico 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 o token OIDC ID que serve de base para elas
  • Isso é semelhante ao caso em que credenciais de longo prazo estão no workflow, mas as credenciais de Trusted Publishing não têm o mesmo risco de escopo e duração
  • O PyPI mitiga o risco de comprometimento de CI/CD recusando troca de tokens para identidades de máquina correspondentes a gatilhos fáceis de abusar, 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 o 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 usar Trusted Publisher para publicar
  • Também é possível enviar malware ou código vulnerável usando Trusted Publisher
  • Nesse ponto, ele é igual aos tokens de API, outro método de autenticação de upload do PyPI
• Trusted Publishing não é obrigatório no PyPI e não poderá se tornar obrigatório no futuro
  • Forçar os usuários a adotar Trusted Publishing é inviável do ponto de vista de engenharia e também não é desejável técnica nem socialmente
  • Trusted Publishing sempre será opcional

Como a UI 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 indicador verde para estados sob controle do usuário é usado apenas em links cuja origem o PyPI consegue provar que veio da mesma fonte do próprio pacote
• URLs verificadas apenas provam que, no momento da verificação, aquela URL estava sob controle do dono do pacote no PyPI, e não significam segurança adicional para a URL ou para o projeto
• O estado de Trusted Publishing de um arquivo específico é mostrado apenas como um valor simples de Yes/No nos detalhes do arquivo
  • A área de metadados do arquivo não é renderizada como se fosse informação importante para o julgamento de confiança do usuário
  • Nem mesmo o blob JSON vindo do user agent do cliente de upload é renderizado de forma adequada

Distinção em relação a 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 é semelhante a 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 próprio controle
• Ter um Trusted Publisher não significa necessariamente que exista uma attestation, e ter uma attestation também não quer dizer 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

[GN⁺]

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)

  • O Trusted Publishing não implica aprisionamento (lock-in). É possível usar outro método de autenticação a qualquer momento, inclusive hosts com os quais o PyPI possa se integrar
    Há certa ironia em chamar autenticação federada de uma forma de aprisionamento
  • A auto-hospedagem, na prática, quase sempre foi algo de nicho. O objetivo do SourceForge era justamente assumir esse ônus
    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
  • Há algum motivo para não ser possível fazer Trusted Publishing em um Forgejo auto-hospedado? Se houver, acho que estou deixando algo passar