Preuve s’il en est que Debian n’a pas besoin des clefs Microsoft 
Quand je vous dit que ce n’est qu’un remake de la daube de l’an 2000 
complètement, ca veut dire que tu n’es pas en UEFI
²
Bien sur que si, le shim-signed est signé avec la clef microsoft 2011 actuellement:
/tmp]$ sbverify --list /media/francois/61B9-05E6/EFI/BOOT/shimx64.efi
warning: data remaining[833960 vs 960080]: gaps between PE/COFF sections?
signature 1
image signature issuers:
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows UEFI Driver Publisher
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root
[/tmp]$ Cela est indispensable pour bouter une clef live sur une machine avec le secure boot. Il est probable que les mises à jour à venir vont mettre un shimx64.efi signé avec le nouveau certificat. Ça ne fonctionne pas comme les certificats des sites, le 26 juin 2026, il ne se passera rien, le certitificat 2011 sera encore utilisé pour valider les noyaux, simplement il ne sera plus utilisé pour signer des nouveaux noyaux windows. Cela signifie juste que les noyaux windows signés après cette date ne fonctionneront pas avec les anciennes machines sans rajout du cettificat. En ce qui concerne linux, la compatibilité descendante fait que pendant pas mal de temps, les noyaux seront signés avec les deux certificats. Bref, pour moi rien à faire si ce n’est prendre un café et attendre tranquillement sans souci pendant qques années.
Ta machine est en multi-booTourst? sous Grub? c’est pour ça que tu as microsoft. Sans multiboot avec Windows il n’y a aucune raison que ce soit signé avec Microsoft. Ou alors tu utilises les fichiers par defaut (comme BOOTX64.efi).
D’ailleurs quand tu utilise UKI et systemd-boot, il n’y a pas de signature Microsoft:
- BOOTX64.efi a les signature microsoft parce que c’est mis par défaut dans la structure UEFI.
- shimx64.efi ne prend que ce qui lui est demandé:
Lié à Grub:
sbverify --list /mnt/boot/efi/EFI/debian/shimx64.efi
warning: data remaining[831016 vs 957136]: gaps between PE/COFF sections?
signature 1
image signature issuers:
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows UEFI Driver Publisher
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root
Sans GRUB avec systemd-boot:
~# sbverify --list /mnt/boot/efi/EFI/systemd/systemd-bootx64.efi
signature 1
image signature issuers:
- /CN=Debian Secure Boot CA
image signature certificates:
- subject: /CN=Debian Secure Boot Signer 2024 - 20425036 - systemd-boot
issuer: /CN=Debian Secure Boot CA
Avec UKI (anonymisé car ce sont mes propres clefs/certificats de signature):
~# sbverify --list /mnt/boot/efi/EFI/Linux/debian.efi
signature 1
image signature issuers:
- /C=FR/ST=*/L=*/O=*/OU=Secure Boot Cert/CN=*
image signature certificates:
- subject: /C=FR/ST=*/L=Tours/O=*/OU=Secure Boot Cert/CN=*
issuer: /C=FR/ST=*/L=*/O=*/OU=Secure Boot Cert/CN=*
Hors grub et fichier UEFI standard, et éventuellement multiboot avec windows, il n’y a aucune signature microsoft. (sur ce type d’installation, sans GRUB et sans Multiboot, j’ai fait plus de 300 tests).
C’est d’ailleurs une des (nombreuses) raisons qui m’ont fait définitivement abandonné GRUB.
Et c’est aussi pour ça que je dit que cette histoire est un piège du même ordre de grandeur que le soit disant bug de l’an 2000.
Non, j’ai fait une clef (clef distribué par l’association APESAM), clef live contenant des logiciels utiles à l’enseignement en Maths, Physique, SI, SNV, FLE, Info ainsi que des éditeurs, etc. Cette clef doit bouter sur toutes les machines quelles qu’elles soient. Je suis donc tenu de mettre un système de boot validé par le BIOS donc signé par microsoft. Microsoft a signé le shimx64 qui lui vérifie la signature des noyaux (si j’ai bien compris). Ce shim est fourni par le paquet shim-signed (il y a aussi un shim-unsigned) qui lui démarre les noyaux debian. Il me faut cette signature microsoft pour que cette clef puisse marcher sur les PCs classiques vieux ou récents voire très récents, et ce, sans y toucher.
Sur ma machine, je m’en tape, je n’ai pas le secure boot et je compile mon noyau. Je n’ai pas eu de machine sous windows depuis 1999.
L’amusant est qu’on peut faire une clef live boutant sur des PC X86_64, des machines AARCH64 (arm 64bits) dont les raspberry (qui sont particuliers). En revanche, si la clef démarre sur des Mac Intel, Apple a définitivement écarté toute méthode pour démarrer une clef linux sans avoir installé un truc sur les Mac arm64.
Le boot de la clef ne concerne que la clef.
du média sur lequel le démarrage se fait.
Non là le système s’en balance car sans secure boot, il n’y a aucune vérification des signature. Après tout dépend ce que tu appelles ancien 
J’avoue que pour moi MAC n’est utilise que pour se la péter sur une étagère, ce depuis que le macintosh et ses copains de l’époque n’existent plus.
Le truyc qu’il faut comprendre c’est que si tu installes un système avec secure boot qui utilise une signature microsoft , c’est parce qu’un paquet ou une copie directe de fichier l’y a mis.
Le processus d’installation ne le fait en aucun cas.
Ce qui fait que si tu signes tes fichier .efi avec ta clef/certificat, tu peux dégommer Microsoft aussi sec sans impact.
Cependant, il faut faire très attention car le chargement d’un système de démarrage va charger d’abord le noyau EFI avant de charger l’autre noyau efi qui lui lancera le système.
C’est là que la difficulté apparaît.
Il faut d’assurer d’avoir ses propres certificats dans les diverses bank du secure boot avant de faire l’opération de suppression des certificats microsoft.
Ce n’est pas compliqué mais il faut être méticuleux et bien respecter la chaine des opérations.
Autre petit aspect: l’utilisation de clefs microsoft implique que tout le monde a la même dans le KEK par exemple.
Ben il est installé avec le paquet shim-signed:
[/]# sbverify --list .//usr/lib/shim/shimx64.efi
warning: data remaining[824320 vs 950440]: gaps between PE/COFF sections?
No signature table present
[/]# sbverify --list .//usr/lib/shim/shimx64.efi.signed
warning: data remaining[833960 vs 960080]: gaps between PE/COFF sections?
signature 1
image signature issuers:
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows UEFI Driver Publisher
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root
root@talon:/# dpkg -S /usr/lib/shim/shimx64.efi.signed
shim-signed:amd64: /usr/lib/shim/shimx64.efi.signed
root@talon:/# Encore une fois, je n’ai pas loisir de modifier les machines qui vont faire tourner cette clef, elles sont au Sénégal, en Ouzbékistan, au Liban, etc. Pire, apparemment désormais si tu enlèves et remet le secure boot avec Windows 11, ce dernier activant par defaut Bitlocker, au reboute la machine te demande la clef du Bitlocker. Ça avait mis dans la panade plusieurs personnes. Mon but est que la clef démarre sur une machine avec n’importe quoi dessus (donc windows 11) sans qu’il n’y ait autre chose à faire que d’avoir le menu de boot et il est atteint avec juste l’installation de grub+shim-signed avec les noyaux debian (signés) (backport ou non)
Dans ma boite, 1200 personnes ont été affectées.
C’est une malfaçon de Microsoft dans des mises à jour d’octobre dernier et de janvier.
Nuls mais constants, conformes aux attendus.
OK.
Si j’installe shim-signed et toutes ses dépendances (grub-efi-amd64-bin…), ça ne va pas mettre le binz dans mon démarrage ?
Ca ne sert à rien si tu n’es pas en EUFI.
Et je crois (à vérifier) qu’en installant shim ça va modifier tes paquets GRUB et donc ton installation GRUB.
Ça change juste le binaire shimx64.efi dans la partition boot en la remplaçant la version unsigned par la signed. C’est en amont de grub, donc ça ne change rien sur la config.