Trusted Publishing no debe verse como una señal de confianza del paquete
(blog.yossarian.net)- La “confianza” de Trusted Publishing no significa que una persona pueda confiar en el paquete, sino que se refiere a una relación de autenticación para la carga entre una identidad de máquina externa, como CI/CD, y un índice de paquetes
- La implementación de PyPI funciona sobre una federación OIDC y, en lugar de tokens de API de larga duración, emite credenciales de publicación de corta duración y alcance reducido, lo que disminuye la exposición de credenciales de larga duración y con permisos excesivos
- Después de que PyPI lo publicara en 2023, se extendió a npm, RubyGems, crates.io, NuGet y otros, pero siguen existiendo la complejidad del modelo de datos, el tratamiento específico de cada proveedor OIDC y la posibilidad de compromiso de CI/CD
- PyPI no destaca el estado de Trusted Publishing en la página del proyecto con una marca de verificación verde, sino que lo muestra solo como metadatos simples Yes/No en los detalles del archivo, reduciendo la posibilidad de que se malinterprete como una señal de seguridad
- Trusted Publishing y las attestations de PyPI solo indican si hubo autenticación de carga o firma basada en identidad de máquina; por sí solas no permiten juzgar la seguridad ni la calidad del paquete hasta que se confíe por separado en esa identidad
El alcance de la confianza que aborda Trusted Publishing
- Trusted Publishing no es una función que le diga a las personas que confíen en un paquete, sino un método de autenticación que trata la confianza entre máquinas
- Ver Trusted Publishing como un problema de si una persona puede confiar o no desplaza la discusión a la categoría equivocada
- El punto central es establecer una relación de confianza para la autenticación de carga entre una identidad de máquina externa, como un flujo de trabajo de CI/CD, y la identidad de un proyecto en el índice de paquetes
La estructura de Trusted Publishing en PyPI
- “Trusted Publishing” es el término que usa PyPI para describir un método de autenticación sobre una federación de OpenID Connect
- PyPI lo publicó en 2023 y, desde entonces, también lo adoptaron npm, RubyGems, crates.io, NuGet, entre otros
- El punto de partida son dos problemas
- Los tokens de API del índice, que son credenciales de larga duración, son difíciles de gestionar de forma segura, y a los usuarios les cuesta definir privilegios mínimos y periodos de expiración, por lo que tienden a configurarse con permisos excesivos
- Muchos usuarios crean credenciales para colocarlas en una plataforma de CI/CD, y las plataformas de CI/CD también tienen mecanismos para demostrar, mediante OIDC, el control de una identidad de máquina específica
- El usuario registra una sola vez en el índice de paquetes un Trusted Publisher, que es una identidad de máquina de CI/CD; cuando CI/CD presenta un token de identidad, el índice lo verifica y emite credenciales de publicación de corta duración y alcance reducido
Ventajas y limitaciones que permanecen
- El enfoque de credenciales de corta duración y alcance propio se considera un gran éxito para los usuarios de PyPI
- Los usuarios prefieren no gestionar credenciales directamente cuando no es necesario
- Los grandes proyectos open source y las empresas prefieren la propiedad de que los permisos de publicación estén vinculados a una identidad de origen y no a un maintainer individual
- Trusted Publishing todavía conserva complejidades estructurales
- Los “pending publishers” de PyPI resuelven el problema de proyectos inexistentes, pero complican el modelo de datos y resultan más confusos para los usuarios que el Trusted Publishing general
- Los proveedores OIDC pueden incluir distintos valores en el conjunto de claims, además de algunos claims comunes, por lo que el índice debe tratar por separado la forma particular de cada proveedor
- Por eso, las identidades de máquina no son intercambiables entre IdP OIDC, y esta es una de las razones por las que PyPI agrega lentamente nuevos proveedores de Trusted Publishing
- Si un flujo de trabajo de CI/CD se ve comprometido, un atacante puede filtrar credenciales de Trusted Publishing o el token de ID OIDC que sirve como semilla de esas credenciales
- Es similar a cuando hay credenciales de larga duración dentro del flujo de trabajo, pero las credenciales de Trusted Publishing no tienen el mismo riesgo de alcance y vida útil
- PyPI mitiga el riesgo de compromiso de CI/CD rechazando el intercambio de tokens para identidades de máquina correspondientes a disparadores que pueden abusarse fácilmente, como
pull_request_target
Por qué no es una señal de confianza del paquete
- Trusted Publishing es solo un método de autenticación y no ofrece información sobre si el paquete es seguro, de alta calidad o recomendable para usar
- PyPI es un índice público donde cualquiera puede subir paquetes, y cualquiera puede subir usando un Trusted Publisher
- Incluso con un Trusted Publisher se puede subir malware o código vulnerable
- En este punto es igual que los tokens de API, el otro método de autenticación de carga de PyPI
- Trusted Publishing no es obligatorio en PyPI, y tampoco podrá serlo en el futuro
- Imponer Trusted Publishing a los usuarios es inviable desde el punto de vista de ingeniería y tampoco es deseable técnica ni socialmente
- Trusted Publishing siempre es opcional
Cómo la UI de PyPI reduce malentendidos
- PyPI tiene cuidado de que los usuarios no malinterpreten el estado de Trusted Publishing como una señal de confianza del paquete
- En la página del proyecto no hay una marca de verificación verde que indique el estado de Trusted Publishing
- Las marcas de verificación verdes sobre estados controlados por el usuario solo se usan en enlaces para los que PyPI puede demostrar que provienen de la misma fuente que el propio paquete
- Una URL verificada solo demuestra que, en el momento de la verificación, esa URL estaba bajo el control del propietario del paquete de PyPI; no implica seguridad adicional sobre la URL ni sobre el proyecto
- El estado de Trusted Publishing de un archivo específico se muestra en los detalles del archivo como un valor simple Yes/No
- El área de metadatos del archivo no se renderiza como si fuera información importante para el juicio de confianza del usuario
- Tampoco renderiza correctamente el blob JSON que viene del user agent del cliente de carga
Distinción con las attestations
- Este punto es independiente de las attestations de PyPI
- Las attestations también usan actualmente identidades de máquina OIDC, pero no son una señal de confianza
- Una attestation se parece a una firma sobre una identidad de máquina, pero como cualquiera puede subir a PyPI, cualquiera puede firmar con una identidad de máquina que controla
- Que exista un Trusted Publisher no significa necesariamente que exista una attestation, y que exista una attestation tampoco significa que el usuario final pueda confiar en una identidad específica
- El modelo de confiabilidad de las attestations de PyPI también documenta este punto
1 comentarios
Opiniones en Lobste.rs
Buen artículo. Trusted Publishing y la atestación (attestation) ofrecen garantías distintas frente a diferentes modos de falla, y ambas son además algo separado de la confianza de la que habla la mayoría de los usuarios
Que Trusted Publishing haya sido posible se debe a que, durante los últimos 15 años, muchos proyectos de código abierto pasaron de un autoalojamiento con listas de correo, repositorios Git, rastreadores de errores y servidores de compilación a forjas centralizadas
Ahora que las desventajas de las forjas centralizadas se ven con más claridad, los proyectos están volviendo a considerar el autoalojamiento
En la década de 2010, la conveniencia y los efectos de red social empujaron a los proyectos hacia las forjas centralizadas, pero ahora hay muchos más factores que los mantienen atados, incluido Trusted Publishing
Desconfía de la autoridad — promueve la descentralización
— "The Hacker Ethics", Hackers: Heroes of the Computer Revolution (Steven Levy, 1984)
Hay cierta ironía en llamar lock-in a un método de autenticación federada
Casi al mismo tiempo, hace unos 25 años, también existía la ASF, pero en la ASF había además una carga importante de gobernanza. Antes de eso estaba el proyecto GNU, que ponía más énfasis en la ideología del software libre y menos en un servicio sistemático de hosting de proyectos. GNU existía desde antes de que hubiera una idea clara de qué servicios necesitaban los proyectos de software libre
En los años 90, los proyectos de software libre solían estar alojados en servicios de tiempo compartido de universidades o en servidores de colocación de algún amigo. Por ejemplo, PuTTY o Hyperreal.org, donde estuvo Apache httpd antes de la ASF
Eran pocos los proyectos que crecían lo suficiente como para justificar una infraestructura propia, y el hosting barato también es algo relativamente reciente