rhboot/shim-reviewRecensioni di shim
Questo repository è per la revisione delle richieste di firma del shim. Per creare una richiesta di revisione:
Nota che abbiamo esperienza solo con l'uso di GRUB2 o systemd-boot su Linux, quindi chiederci di approvare qualsiasi altra cosa per la firma richiederà una certa convinzione da parte vostra.
A partire dal 20 ottobre 2025, i shim inviati a Microsoft verranno firmati con le chiavi 2011 e 2023. Per ogni shim inviato, riceverai due copie indietro, ciascuna firmata con una chiave diversa. Ecco le informazioni più recenti da Microsoft: https://techcommunity.microsoft.com/blog/hardware-dev-center/signing-with-the-new-2023-microsoft-uefi-certificates-what-submitters-need-to-kn/4455787
Nuovi requisiti di firma sono inoltre entrati in vigore e sono disponibili qui: https://techcommunity.microsoft.com/blog/hardware-dev-center/updated-microsoft-uefi-signing-requirements/1062916 Tieni presente che sottoporsi a questa revisione shim ti esonera dagli audit di sicurezza annuali, purché il tuo shim passi il controllo solo a boot loader open source.
Suggerimento: controlla la directory docs in questo repository per indicazioni sulla presentazione e per ottenere la firma del tuo shim.
Ecco il modello:
Nome dell'organizzazione e sito web:
[il tuo testo qui]
I revisori dovrebbero poter verificare facilmente che la tua organizzazione sia un'entità legale, per prevenire abusi. Fornisci le informazioni che possono provare l'autenticità con certezza.
Registri delle imprese o equivalenti:
(un collegamento alla voce dell'organizzazione nel registro della tua giurisdizione andrà bene)
[il tuo testo qui]
I dettagli pubblici sia della tua organizzazione che dell'emittente nel certificato EV utilizzato per firmare i file .cab presso Microsoft Hardware Dev Center File Signing Services.
(non il certificato CA incorporato nel tuo shim binario)
Esempio:``` Issuer: O=MyIssuer, Ltd., CN=MyIssuer EV Code Signing CA Subject: C=XX, O=MyCompany, Inc., CN=MyCompany, Inc.
*******************************************************************************
### A quale prodotto o servizio è destinato?
*******************************************************************************
[your text here]
*******************************************************************************
### Qual è la giustificazione per cui è davvero necessario firmarlo affinché tutto il mondo possa avviarlo?
*******************************************************************************
[your text here]
*******************************************************************************
### Perché non puoi riutilizzare shim da un'altra distribuzione già firmata?
*******************************************************************************
[your text here]
*******************************************************************************
### Chi è il contatto principale per gli aggiornamenti di sicurezza, ecc.?
I contatti per la sicurezza devono essere verificati prima che lo shim possa essere accettato. Per richieste successive, la verifica del contatto è necessaria solo se i contatti per la sicurezza o le loro chiavi PGP sono cambiati dall'ultima verifica riuscita.
Un revisore autorizzato avvierà la verifica del contatto inviando a ciascun contatto per la sicurezza un'email crittografata con PGP contenente parole casuali.
Ti verrà chiesto di pubblicare il contenuto di queste email nel tuo problema `shim-review` per dimostrare la proprietà degli indirizzi email e delle chiavi PGP.
Carica le chiavi PGP su un keyserver noto come keyserver.ubuntu.com e/o includile nella revisione come file .asc, e segnalale qui.
*******************************************************************************
- Nome:
- Posizione:
- Indirizzo email:
- Impronta della chiave PGP:
- Percorso file/keyserver:
*******************************************************************************
### Chi è il contatto secondario per gli aggiornamenti di sicurezza, ecc.?
*******************************************************************************
- Nome:
- Posizione:
- Indirizzo email:
- Impronta della chiave PGP:
- Percorso file/keyserver:
*******************************************************************************
### Questi binari sono stati creati dal tarball della release 16.1 di shim?
Crea i tuoi binari shim a partire dal tarball della release 16.1 di shim: https://github.com/rhboot/shim/releases/download/16.1/shim-16.1.tar.bz2
Ciò corrisponde a https://github.com/rhboot/shim/releases/tag/16.1 e contiene il codice sorgente gnu-efi appropriato.
Assicurati che il tarball sia corretto verificando il checksum del tuo download
(SHA256, SHA512) con i seguenti:```
46319cd228d8f2c06c744241c0f342412329a7c630436fce7f82cf6936b1d603 shim-16.1.tar.bz2
ca5f80e82f3b80b622028f03ef23105c98ee1b6a25f52a59c823080a3202dd4b9962266489296e99f955eb92e36ce13e0b1d57f688350006bba45f2718f159fb shim-16.1.tar.bz2
Assicurati di aver verificato che il tuo processo di build utilizzi quel file come fonte di verità (escluse le patch esterne) e che il suo checksum corrisponda. Puoi anche convalidare ulteriormente il rilascio controllando la firma PGP: c'è una firma distaccata
Il rilascio è firmato dal manutentore Peter Jones - la sua chiave master ha l'impronta digitale B00B48BC731AA8840FED9FB0EED266B70F4FEF10 e la sottochiave di firma in questa firma ha l'impronta digitale 02093E0D19DDE0F7DFFBB53C1FD3F540256A1372. Una copia della sua chiave pubblica è inclusa qui come riferimento:
pjones.asc
Una volta che sei sicuro che il tarball che stai utilizzando sia corretto e autentico, confermalo qui con un semplice sì.
Una breve guida sulla verifica delle chiavi pubbliche e delle firme dovrebbe essere disponibile nella directory docs.
[your text here]
Suggerimento: Se alleghi tutte le patch e le modifiche utilizzate alla tua applicazione, puoi indicare qui l'URL della tua applicazione (https://github.com/YOUR_ORGANIZATION/shim-review).
Puoi anche indicare i tuoi server git personalizzati, dove è ospitato il codice.
[your url here]
Menziiona tutte le patch esterne e le modifiche al processo di build, che vengono utilizzate durante il tuo processo di compilazione, che rendono il tuo binario shim quello esatto che hai pubblicato come parte di questa richiesta.
[your text here]
Vedi https://techcommunity.microsoft.com/t5/hardware-dev-center/nx-exception-for-shim-community/ba-p/3976522 per maggiori dettagli sulla firma di shim senza bit NX.
[your text here]
Salta questa domanda se non stai utilizzando GRUB2.
[your text here]
Salta questa domanda se non stai utilizzando GRUB2, altrimenti assicurati che siano presenti e conferma con sì.
[your text here]
Salta questa domanda se non stai utilizzando GRUB2, altrimenti hai una voce nel tuo binario GRUB2 simile a:
grub,5,Free Software Foundation,grub,GRUB_UPSTREAM_VERSION,https://www.gnu.org/software/grub/?
[your text here]
Se non avevi uno shim firmato in precedenza, dillo qui. Altrimenti un semplice sì andrà bene.
[your text here]
Suggerimento: i kernel upstream dovrebbero avere tutti questi applicati, ma se distribuisci la tua versione di kernel più vecchia pesantemente modificata, mantenuta separatamente dall'upstream, potrebbe non essere così.
Se stai distribuendo un kernel più vecchio, ricontrolla le tue fonti; forse non hai tutte le patch, ma distribuisci una configurazione che non espone il(i) problema(i).
[your text here]
Suggerimento: Se non lo fa, è improbabile che firmiamo il tuo shim.
[your text here]
[your text here]
[your text here]
[your text here]
Questo garantisce che il tuo nuovo shim+GRUB2 non possa più caricare a catena quei vecchi binari GRUB2 con problemi.
Se questa è la tua prima richiesta o stai utilizzando un nuovo certificato CA, dillo qui.
[your text here]
Un revisore dovrebbe sempre essere in grado di eseguire docker build . per ottenere il binario esatto che hai allegato nella tua richiesta.
Suggerimento: Preferisci utilizzare pacchetti congelati per la tua toolchain, poiché un aggiornamento di GCC, binutils, gnu-efi potrebbe portare alla costruzione di un binario shim con un checksum diverso.
Se i tuoi binari shim non possono essere riprodotti utilizzando il Dockerfile fornito, spiega perché, quali sarebbero le differenze e quale ambiente di build (SO e toolchain) viene utilizzato per riprodurre questa build? In questo caso, scrivi una guida dettagliata su come configurare questo ambiente di build da zero.
[your text here]
Questo dovrebbe includere i log per la creazione dei buildroot, l'applicazione delle patch, l'esecuzione della build, la creazione degli archivi, ecc.
[your text here]
Ad esempio, firma di nuove varianti del kernel, UKI, systemd-boot, nuovi certificati, nuova CA, ecc.
Salta questa domanda se questa è la tua prima richiesta per far firmare shim.
[your text here]
[your text here]
Descrivi la strategia di sicurezza utilizzata per la protezione delle chiavi. Può variare dall'uso di token hardware come HSM o smartcard, caveau air-gapped, casseforti fisiche ad altre buone pratiche.
[your text here]
Un sì o no andrà bene. Non c'è penalità per il secondo.
[your text here]
Un sì o no andrà bene. Non c'è penalità per il secondo. Tuttavia, se sì: quel certificato include i vincoli di base X509v3 per indicare che è una CA? Vedi la documentazione per ulteriori indicazioni.
[your text here]
Suggerimento: La storia di SBAT e maggiori informazioni su come funziona si trovano qui. Quel documento è grande, quindi per alcuni esempi consulta SBAT.example.md
Se stai utilizzando un'implementazione downstream di GRUB2 (ad esempio da Fedora o Debian), assicurati di conservare le loro voci SBAT e di aggiungere le tue (non sostituire le loro) per semplificare la revoca.
Ricordati di pubblicare le voci di tutti i binari. Oltre al bootloader, potresti anche distribuire, ad esempio, un aggiornatore firmware, che avrà anche queste.
Suggerimento: esegui objcopy --dump-section .sbat=/dev/stdout YOUR_EFI_BINARY per ottenere queste voci. Incollale qui. Preferibilmente racchiudi ogni elenco con tre backtick (```), in modo che vengano visualizzati correttamente.
[your text here]
Salta questa domanda se non stai utilizzando GRUB2.
Suggerimento: si tratta dei moduli che sono nel binario stesso, non dei file .mod nel tuo filesystem.
[your text here]
[your text here]
[your text here]
Suggerimento: Il caso più comune qui sarà un aggiornatore firmware come fwupd.
[your text here]
Salta questa domanda se non stai utilizzando GRUB2 o systemd-boot.
[your text here]
Riassumi in una o due frasi come funziona la tua catena di avvio sicuro a livello superiore.
[your text here]
[your text here]
[your text here]
Il processo di revisione è inteso come uno sforzo di peer-review e il modo migliore per far revisionare più rapidamente la tua richiesta è aiutare a revisionare quelle degli altri. Nella maggior parte dei casi siamo volontari che lavorano su questo spazio nel tempo libero, piuttosto che essere impiegati e pagati per revisionare le richieste durante l'orario di lavoro.
Un periodo di attesa ragionevole per una revisione può arrivare a 2-3 mesi. Aiutarci è il modo migliore per accorciare questo periodo. Più aiuto riceviamo, più velocemente e più fluidamente le cose procederanno.
Per i nuovi arrivati, si consiglia di iniziare il processo di contribuzione con le richieste etichettate come facili da revisionare.
[your text here]
[your text here]