rhboot/shim-reviewReseñas de shim
Este repositorio es para la revisión de solicitudes de firma de shim. Para crear una solicitud de revisión:
Ten en cuenta que realmente solo tenemos experiencia con el uso de GRUB2 o systemd-boot en Linux, por lo que pedirnos que respaldemos cualquier otra cosa para su firma requerirá cierta convicción de tu parte.
A partir del 20 de octubre de 2025, los shims enviados a Microsoft se firmarán con las claves de 2011 y 2023. Por cada shim que envíes, recibirás dos copias de vuelta, cada una firmada con una clave diferente. Aquí está la información más reciente de Microsoft: https://techcommunity.microsoft.com/blog/hardware-dev-center/signing-with-the-new-2023-microsoft-uefi-certificates-what-submitters-need-to-kn/4455787
También han entrado en vigor nuevos requisitos de firma, disponibles aquí: https://techcommunity.microsoft.com/blog/hardware-dev-center/updated-microsoft-uefi-signing-requirements/1062916 Ten en cuenta que someterte a esta revisión de shim te exime de las auditorías de seguridad anuales, siempre que tu shim solo entregue el control a cargadores de arranque de código abierto.
Pista: consulta el directorio docs en este repositorio para obtener orientación sobre el envío y cómo firmar tu shim.
Aquí está la plantilla:
Nombre de la organización y sitio web:
[tu texto aquí]
Los revisores deben poder verificar fácilmente que tu organización es una entidad legal, para evitar abusos. Proporciona la información que pueda demostrar la autenticidad con certeza.
Inscripciones en el registro mercantil/fiscal o equivalentes:
(un enlace a la entrada de la organización en el registro de tu jurisdicción servirá)
[tu texto aquí]
Los datos públicos tanto de tu organización como del emisor en el certificado EV utilizado para firmar archivos .cab en los Servicios de Firma de Archivos del Centro de Desarrollo de Hardware de Microsoft.
(no el certificado de CA incrustado en tu binario shim)
Ejemplo:``` Issuer: O=MyIssuer, Ltd., CN=MyIssuer EV Code Signing CA Subject: C=XX, O=MyCompany, Inc., CN=MyCompany, Inc.
*******************************************************************************
### ¿Para qué producto o servicio es esto?
*******************************************************************************
[your text here]
*******************************************************************************
### ¿Cuál es la justificación de que realmente necesite estar firmado para que todo el mundo pueda arrancarlo?
*******************************************************************************
[your text here]
*******************************************************************************
### ¿Por qué no puede reutilizar el shim de otra distribución que ya está firmado?
*******************************************************************************
[your text here]
*******************************************************************************
### ¿Quién es el contacto principal para actualizaciones de seguridad, etc.?
Los contactos de seguridad deben ser verificados antes de que el shim pueda ser aceptado. Para solicitudes posteriores, la verificación de contacto solo es necesaria si los contactos de seguridad o sus claves PGP han cambiado desde la última verificación exitosa.
Un revisor autorizado iniciará la verificación de contacto enviando a cada contacto de seguridad un correo electrónico cifrado con PGP que contenga palabras aleatorias.
Se le pedirá que publique el contenido de estos correos en su problema de `shim-review` para demostrar la propiedad de las direcciones de correo electrónico y las claves PGP.
Cargue las claves PGP en un servidor de claves conocido como keyserver.ubuntu.com y/o inclúyalas en la revisión como un archivo .asc, y señálelas aquí.
*******************************************************************************
- Nombre:
- Puesto:
- Correo electrónico:
- Huella digital de la clave PGP:
- Ubicación del archivo/servidor de claves:
*******************************************************************************
### ¿Quién es el contacto secundario para actualizaciones de seguridad, etc.?
*******************************************************************************
- Nombre:
- Puesto:
- Correo electrónico:
- Huella digital de la clave PGP:
- Ubicación del archivo/servidor de claves:
*******************************************************************************
### ¿Estos binarios fueron creados a partir del archivo tar de la versión 16.1 de shim?
Cree sus binarios shim comenzando con el archivo tar de la versión 16.1 de shim: https://github.com/rhboot/shim/releases/download/16.1/shim-16.1.tar.bz2
Esto coincide con https://github.com/rhboot/shim/releases/tag/16.1 y contiene el código fuente gnu-efi adecuado.
Asegúrese de que el tarball sea correcto verificando la suma de comprobación (SHA256, SHA512) de su descarga con las siguientes:```
46319cd228d8f2c06c744241c0f342412329a7c630436fce7f82cf6936b1d603 shim-16.1.tar.bz2
ca5f80e82f3b80b622028f03ef23105c98ee1b6a25f52a59c823080a3202dd4b9962266489296e99f955eb92e36ce13e0b1d57f688350006bba45f2718f159fb shim-16.1.tar.bz2
Asegúrate de que hayas verificado que tu proceso de compilación utiliza ese archivo como fuente de verdad (excluyendo parches externos) y que su suma de verificación coincide. También puedes validar aún más el lanzamiento verificando la firma PGP: hay una firma separada
El lanzamiento está firmado por el mantenedor Peter Jones - su clave maestra tiene la huella digital B00B48BC731AA8840FED9FB0EED266B70F4FEF10 y la subclave de firma en esta firma tiene la huella digital 02093E0D19DDE0F7DFFBB53C1FD3F540256A1372. Se incluye una copia de su clave pública aquí como referencia: pjones.asc
Una vez que estés seguro de que el tarball que estás utilizando es correcto y auténtico, por favor confírmalo aquí con un simple sí.
Una guía breve sobre la verificación de claves públicas y firmas debería estar disponible en el directorio docs.
[tu texto aquí]
Sugerencia: Si adjuntas todos los parches y modificaciones que se están utilizando a tu solicitud, puedes apuntar a la URL de tu aplicación aquí (https://github.com/YOUR_ORGANIZATION/shim-review).
También puedes apuntar a tus servidores git personalizados, donde se aloja el código.
[tu url aquí]
Menciona todos los parches externos y modificaciones del proceso de compilación que se utilizan durante tu proceso de construcción, que hacen que tu binario shim sea exactamente el que publicaste como parte de esta solicitud.
[tu texto aquí]
Consulta https://techcommunity.microsoft.com/t5/hardware-dev-center/nx-exception-for-shim-community/ba-p/3976522 para obtener más detalles sobre la firma de shim sin el bit NX.
[tu texto aquí]
Omite esto si no estás usando GRUB2.
[tu texto aquí]
Omite esto si no estás usando GRUB2, de lo contrario asegúrate de que estén presentes y confirma con sí.
[tu texto aquí]
Omite esto si no estás usando GRUB2; de lo contrario, ¿tienes una entrada en tu binario GRUB2 similar a:
grub,5,Free Software Foundation,grub,GRUB_UPSTREAM_VERSION,https://www.gnu.org/software/grub/?
[tu texto aquí]
Si no tenías un shim firmado anteriormente, indícalo aquí. De lo contrario, un simple sí será suficiente.
[tu texto aquí]
Sugerencia: los kernels upstream deberían tener todos estos aplicados, pero si distribuyes tu propia versión de kernel antiguo muy modificada, que se mantiene por separado del upstream, esto puede no ser el caso.
Si estás distribuyendo un kernel antiguo, verifica tus fuentes; tal vez no tengas todos los parches, pero distribuyas una configuración que no exponga los problemas.
[tu texto aquí]
Sugerencia: Si no lo hace, es poco probable que firmemos tu shim.
[tu texto aquí]
[tu texto aquí]
[tu texto aquí]
[tu texto aquí]
Esto asegura que tu nuevo shim+GRUB2 ya no pueda cargar en cadena esos binarios GRUB2 antiguos con problemas.
Si esta es tu primera solicitud o estás usando un nuevo certificado CA, indícalo aquí.
[tu texto aquí]
Un revisor siempre debería poder ejecutar docker build . para obtener el binario exacto que adjuntaste en tu solicitud.
Sugerencia: Prefiere usar paquetes congelados para tu cadena de herramientas, ya que una actualización de GCC, binutils, gnu-efi puede resultar en la construcción de un binario shim con una suma de verificación diferente.
Si tus binarios shim no pueden reproducirse usando el Dockerfile proporcionado, explica por qué ese es el caso, cuáles serían las diferencias y qué entorno de compilación (SO y cadena de herramientas) se está utilizando para reproducir esta construcción. En ese caso, escribe una guía detallada sobre cómo configurar este entorno de compilación desde cero.
[tu texto aquí]
Esto debería incluir registros para crear los entornos raíz de construcción, aplicar parches, realizar la construcción, crear los archivos, etc.
[tu texto aquí]
Por ejemplo, firma de nuevas variantes del kernel, UKI, systemd-boot, nuevos certificados, nueva CA, etc..
Omite esto si esta es tu primera solicitud para que se firme shim.
[tu texto aquí]
[tu texto aquí]
Describe la estrategia de seguridad que se utiliza para la protección de claves. Esto puede ir desde el uso de tokens de hardware como HSM o tarjetas inteligentes, bóvedas con aislamiento de aire, cajas fuertes físicas hasta otras buenas prácticas.
[tu texto aquí]
Un sí o no será suficiente. No hay penalización por esto último.
[tu texto aquí]
Un sí o no será suficiente. No hay penalización por esto último. Sin embargo, si sí: ¿ese certificado incluye las Basic Constraints X509v3 que indican que es una CA? Consulta la documentación para obtener más orientación sobre esto.
[tu texto aquí]
Sugerencia: El historial de SBAT y más información sobre cómo funciona se puede encontrar aquí. Ese documento es grande, así que para algunos ejemplos consulta SBAT.example.md
Si estás usando una implementación downstream de GRUB2 (por ejemplo, de Fedora o Debian), asegúrate de tener sus entradas SBAT preservadas y que añadas las tuyas (no reemplaces las de ellos) para simplificar la revocación.
Recuerda publicar las entradas de todos los binarios. Además de tu gestor de arranque, también puedes estar distribuyendo, por ejemplo, un actualizador de firmware, que también las tendrá.
Sugerencia: ejecuta objcopy --dump-section .sbat=/dev/stdout YOUR_EFI_BINARY para obtener estas entradas. Pégalas aquí. Preferiblemente rodea cada listado con tres comillas invertidas (```), para que se vean bien.
[tu texto aquí]
Omite esto si no estás usando GRUB2.
Sugerencia: esto se refiere a aquellos módulos que están en el propio binario, no los archivos .mod en tu sistema de archivos.
[tu texto aquí]
[tu texto aquí]
[tu texto aquí]
Sugerencia: El caso más común aquí será un actualizador de firmware como fwupd.
[tu texto aquí]
Omite esto si no estás usando GRUB2 o systemd-boot.
[tu texto aquí]
Resume en una o dos frases cómo funciona tu cadena de arranque seguro a alto nivel.
[tu texto aquí]
[tu texto aquí]
[tu texto aquí]
El proceso de revisión está pensado para ser un esfuerzo de revisión entre pares y la mejor manera de que tu solicitud sea revisada más rápido es ayudar con la revisión de otros. En la mayoría de los casos somos voluntarios que trabajamos en este espacio en nuestro tiempo libre, en lugar de ser empleados y ser pagados para revisar las solicitudes durante nuestras horas de trabajo.
Un plazo razonable de espera para una revisión puede alcanzar los 2-3 meses. Ayudarnos es la mejor manera de acortar este período. Cuanta más ayuda recibamos, más rápido y más fluidas serán las cosas.
Para los recién llegados, las solicitudes etiquetadas como fáciles de revisar se recomiendan para comenzar el proceso de contribución.
[tu texto aquí]
[tu texto aquí]