rhboot/shim-reviewAnálises do shim
Este repositório é para revisão de solicitações de assinatura do shim. Para criar uma solicitação de revisão:
Observe que realmente temos experiência apenas com o uso de GRUB2 ou systemd-boot no Linux, portanto, pedir para endossarmos qualquer outra coisa para assinatura exigirá uma boa dose de convencimento da sua parte.
A partir de 20 de outubro de 2025, os shims enviados para a Microsoft serão assinados com as chaves de 2011 e 2023. Para cada shim que você enviar, receberá duas cópias de volta, cada uma assinada por uma chave diferente. Aqui estão as informações mais recentes da Microsoft: https://techcommunity.microsoft.com/blog/hardware-dev-center/signing-with-the-new-2023-microsoft-uefi-certificates-what-submitters-need-to-kn/4455787
Novos requisitos de assinatura também entraram em vigor e estão disponíveis aqui: https://techcommunity.microsoft.com/blog/hardware-dev-center/updated-microsoft-uefi-signing-requirements/1062916 Observe que passar por esta revisão do shim o isenta de auditorias de segurança anuais, desde que seu shim apenas repasse para bootloaders de código aberto.
Dica: consulte o diretório docs neste repositório para obter orientações sobre envio e como ter seu shim assinado.
Aqui está o modelo:
Nome da organização e site:
[seu texto aqui]
Os revisores devem conseguir verificar facilmente que sua organização é uma entidade legal, para evitar abusos. Forneça as informações que possam comprovar a autenticidade com certeza.
Registros comerciais/fiscais ou equivalentes:
(um link para a entrada da organização no registro de sua jurisdição serve)
[seu texto aqui]
Os detalhes públicos de sua organização e do emissor no certificado EV usado para assinar arquivos .cab no Serviço de Assinatura de Arquivos do Centro de Desenvolvimento de Hardware da Microsoft.
(não o certificado CA incorporado no seu binário shim)
Exemplo:``` Issuer: O=MyIssuer, Ltd., CN=MyIssuer EV Code Signing CA Subject: C=XX, O=MyCompany, Inc., CN=MyCompany, Inc.
*******************************************************************************
### Para qual produto ou serviço é este?
*******************************************************************************
seu texto aqui
*******************************************************************************
### Qual é a justificativa de que isso realmente precisa ser assinado para que todo o mundo possa inicializá-lo?
*******************************************************************************
seu texto aqui
*******************************************************************************
### Por que você não pode reutilizar o shim de outra distribuição que já está assinado?
*******************************************************************************
seu texto aqui
*******************************************************************************
### Quem é o contato principal para atualizações de segurança, etc.?
Os contatos de segurança precisam ser verificados antes que o shim possa ser aceito. Para solicitações subsequentes, a verificação de contato só é necessária se os contatos de segurança ou suas chaves PGP tiverem mudado desde a última verificação bem-sucedida.
Um revisor autorizado iniciará a verificação de contato enviando a cada contato de segurança um e-mail criptografado com PGP contendo palavras aleatórias.
Você será solicitado a postar o conteúdo desses e-mails em seu problema `shim-review` para provar a propriedade dos endereços de e-mail e chaves PGP.
Por favor, faça upload das chaves PGP para um keyserver conhecido, como keyserver.ubuntu.com, e/ou inclua-as na revisão como um arquivo .asc, e aponte para elas aqui.
*******************************************************************************
- Nome:
- Cargo:
- Endereço de e-mail:
- Impressão digital da chave PGP:
- Localização do arquivo/keyserver:
*******************************************************************************
### Quem é o contato secundário para atualizações de segurança, etc.?
*******************************************************************************
- Nome:
- Cargo:
- Endereço de e-mail:
- Impressão digital da chave PGP:
- Localização do arquivo/keyserver:
*******************************************************************************
### Esses binários foram criados a partir do tarball da versão 16.1 do shim?
Por favor, crie seus binários shim a partir do arquivo tar da versão 16.1 do shim: https://github.com/rhboot/shim/releases/download/16.1/shim-16.1.tar.bz2
Isso corresponde a https://github.com/rhboot/shim/releases/tag/16.1 e contém o código fonte apropriado do gnu-efi.
Certifique-se de que o tarball está correto verificando a soma de verificação do seu download
(SHA256, SHA512) com as seguintes:```
46319cd228d8f2c06c744241c0f342412329a7c630436fce7f82cf6936b1d603 shim-16.1.tar.bz2
ca5f80e82f3b80b622028f03ef23105c98ee1b6a25f52a59c823080a3202dd4b9962266489296e99f955eb92e36ce13e0b1d57f688350006bba45f2718f159fb shim-16.1.tar.bz2
Certifique-se de que verificou que o seu processo de compilação usa esse ficheiro como fonte da verdade (excluindo correções externas) e que o seu checksum corresponde. Também pode validar melhor o lançamento verificando a assinatura PGP: existe uma assinatura destacada
O lançamento é assinado pelo mantenedor Peter Jones – a sua chave mestra
tem a impressão digital B00B48BC731AA8840FED9FB0EED266B70F4FEF10 e a
subchave de assinatura na assinatura aqui tem a impressão digital
02093E0D19DDE0F7DFFBB53C1FD3F540256A1372. Uma cópia da sua chave pública
está incluída aqui para referência:
pjones.asc
Depois de ter a certeza de que o tarball que está a usar está correto e autêntico, confirme aqui com um simples sim.
Um guia curto sobre como verificar chaves públicas e assinaturas deve estar disponível no diretório docs.
[seu texto aqui]
Dica: Se anexar todas as correções e modificações que estão a ser usadas na sua aplicação, pode apontar para o URL da sua aplicação aqui (https://github.com/YOUR_ORGANIZATION/shim-review).
Também pode apontar para os seus servidores git personalizados, onde o código está hospedado.
[seu url aqui]
Mencione todas as correções externas e modificações do processo de compilação que são usadas durante o seu processo de compilação, que tornam o seu binário shim exatamente o que publicou como parte desta aplicação.
[seu texto aqui]
Consulte https://techcommunity.microsoft.com/t5/hardware-dev-center/nx-exception-for-shim-community/ba-p/3976522 para mais detalhes sobre a assinatura do shim sem o bit NX.
[seu texto aqui]
Ignore isto, se não estiver a usar GRUB2.
[seu texto aqui]
Ignore isto, se não estiver a usar GRUB2; caso contrário, certifique-se de que estas estão presentes e confirme com sim.
[seu texto aqui]
Ignore isto, se não estiver a usar GRUB2; caso contrário, tem uma entrada no seu binário GRUB2 semelhante a:
grub,5,Free Software Foundation,grub,GRUB_UPSTREAM_VERSION,https://www.gnu.org/software/grub/?
[seu texto aqui]
Se não teve nenhum shim assinado anteriormente, diga-o aqui. Caso contrário, um simples sim serve.
[seu texto aqui]
Dica: os kernels upstream devem ter todos estes aplicados, mas se distribuir a sua própria versão de kernel mais antiga e fortemente modificada, mantida separadamente do upstream, isto pode não ser o caso.
Se estiver a distribuir um kernel mais antigo, verifique as suas fontes; talvez não tenha todas as correções, mas distribua uma configuração que não exponha o(s) problema(s).
[seu texto aqui]
Dica: Se não o fizer, é improvável que assinemos o seu shim.
[seu texto aqui]
[seu texto aqui]
[seu texto aqui]
[seu texto aqui]
Isto garante que o seu novo shim+GRUB2 não pode mais encadear esses binários GRUB2 mais antigos com problemas.
Se esta é a sua primeira aplicação ou está a usar um novo certificado CA, por favor diga-o aqui.
[seu texto aqui]
Um revisor deve ser sempre capaz de executar docker build . para obter o binário exato que anexou na sua aplicação.
Dica: Prefira usar pacotes congelados para a sua toolchain, pois uma atualização do GCC, binutils, gnu-efi pode resultar na construção de um binário shim com um checksum diferente.
Se os seus binários shim não podem ser reproduzidos usando o Dockerfile fornecido, explique por que esse é o caso, quais seriam as diferenças e que ambiente de compilação (SO e toolchain) está a ser usado para reproduzir esta compilação? Nesse caso, escreva um guia detalhado de como configurar este ambiente de compilação a partir do zero.
[seu texto aqui]
Isto deve incluir logs para criar os buildroots, aplicar correções, fazer a compilação, criar os arquivos, etc.
[seu texto aqui]
Por exemplo, assinar novas variantes de kernel, UKI, systemd-boot, novos certificados, novo CA, etc..
Ignore isto, se esta é a sua primeira aplicação para ter o shim assinado.
[seu texto aqui]
[seu texto aqui]
Descreva a estratégia de segurança que é usada para a proteção de chaves. Isto pode variar desde o uso de tokens de hardware como HSMs ou Smartcards, cofres isolados, cofres físicos, a outras boas práticas.
[seu texto aqui]
Um sim ou não serve. Não há penalização para o último.
[seu texto aqui]
Um sim ou não serve. Não há penalização para o último. No entanto, se sim: esse certificado inclui as restrições básicas X509v3 para dizer que é uma CA? Consulte a documentação para mais orientações sobre isto.
[seu texto aqui]
Dica: A história do SBAT e mais informações sobre como funciona podem ser encontradas aqui. Esse documento é grande, por isso, para apenas alguns exemplos, consulte SBAT.example.md
Se está a usar uma implementação downstream do GRUB2 (por exemplo, do Fedora ou Debian), certifique-se de que preserva as entradas SBAT deles e que anexa as suas (não substitua as deles) para simplificar a revogação.
Lembre-se de publicar as entradas de todos os binários. Além do seu bootloader, pode também estar a distribuir, por exemplo, um atualizador de firmware, que também terá estas.
Dica: execute objcopy --dump-section .sbat=/dev/stdout SEU_BINÁRIO_EFI para obter estas entradas. Cole-as aqui. De preferência, envolva cada listagem com três acentos graves (```), para que sejam exibidos corretamente.
[seu texto aqui]
Ignore isto, se não estiver a usar GRUB2.
Dica: trata-se dos módulos que estão no próprio binário, não os ficheiros .mod no seu sistema de ficheiros.
[seu texto aqui]
[seu texto aqui]
[seu texto aqui]
Dica: O caso mais comum aqui será um atualizador de firmware como o fwupd.
[seu texto aqui]
Ignore isto, se não estiver a usar GRUB2 ou systemd-boot.
[seu texto aqui]
Resuma em uma ou duas frases como funciona a sua cadeia de arranque segura num nível superior.
[seu texto aqui]
[seu texto aqui]
[seu texto aqui]
O processo de revisão é um esforço de revisão por pares e a melhor maneira de ter a sua aplicação revista mais rapidamente é ajudar a rever as outras. Na maioria dos casos, somos voluntários a trabalhar nesta plataforma no nosso tempo livre, em vez de sermos empregados e pagos para rever aplicações durante o nosso horário de trabalho.
Um período razoável de espera por uma revisão pode chegar a 2-3 meses. Ajudar-nos é a melhor maneira de encurtar este período. Quanto mais ajuda recebermos, mais rápido e mais suave as coisas funcionarão.
Para recém-chegados, as aplicações marcadas como fáceis de rever são recomendadas para iniciar o processo de contribuição.
[seu texto aqui]
[seu texto aqui]