Re: [RFR] wml://security/2021-GRUB-UEFI-SecureBoot/index.wml
Bonjour,
suggestions dont préférences.
Amicalement.
--
Jean-Paul
--- index.wml 2021-03-04 10:47:21.573942224 +0100
+++ - 2021-03-04 10:59:30.329918162 +0100
@@ -9,7 +9,7 @@
nouveaux problèmes qui pourraient permettre de contourner l'amorçage
sécurisé (<q>Secure Boot</q> — SB) avec UEFI. Plusieurs autres ont été
découverts. Consultez l'<a href="$(HOME)/security/2021/dsa-4867">annonce de
-sécurité de 4867-1</a> pour plus de détails. Le but de ce document est
+sécurité dsa-4867-1</a> pour plus de détails. Le but de ce document est
d'expliquer les conséquences de cette vulnérabilité de sécurité et les
étapes pour sa suppression.
</p>
@@ -80,7 +80,7 @@
est conçu pour fournir une interface de pilote pour ACPI (« Advanced
Configuration and Power Interface »), un composant très commun du matériel
des ordinateurs actuels. Malheureusement, le module ACPI permet aussi
-actuellement à un utilisateur de charger des tables ACPI contrefaites avec
+actuellement à un utilisateur privilégié de charger des tables ACPI contrefaites avec
l'amorçage sécurisé et d'effectuer des modifications arbitraires dans
l'état du système ; cela permet de briser facilement la chaîne d'amorçage
sécurisé. Cette faille de sécurité a maintenant été corrigée.
@@ -88,7 +88,7 @@
<p>
Comme cela a été fait avec BootHole, plutôt que de corriger uniquement ce
-bogue, les développeurs ont poursuivi par un audit et une analyse en
+bogue, les développeurs sont allés plus loin avec un audit et une analyse en
profondeur du code source de GRUB2. Il aurait été irresponsable de ne
corriger qu'un défaut majeur sans également en rechercher d'autres ! Nous
avons découvert quelques autres emplacements où des allocations de mémoire
@@ -100,7 +100,7 @@
<p>
De nouveau, veuillez consulter l'<a
-href="$(HOME)/security/2021/dsa-4867">annonce de sécurité de Debian 4867</a>
+href="$(HOME)/security/2021/dsa-4867">annonce de sécurité dsa-4867 de Debian</a>
pour une liste complète des problèmes découverts.
</p>
@@ -112,7 +112,7 @@
<a href="#package_updates">publier des versions corrigées</a> de GRUB2.
Néanmoins, cela ne peut pas corriger complètement le problème traité
ici. Des acteurs malveillants pourraient encore utiliser des versions
-vulnérables plus anciennes de GRUB2 pour pouvoir contourner l'amorçage
+vulnérables plus anciennes de GRUB2 pour contourner l'amorçage
sécurisé.
<p>
@@ -124,7 +124,7 @@
par Microsoft de fournir des détails sur les binaires ou les clés concernés
pour faciliter ce processus. Le <a
href="https://uefi.org/revocationlistfile";>fichier de la liste de
-révocation d'UEFI</a> sera mis à jour pour inclure cette information. À un
+révocations d'UEFI</a> sera mis à jour pour inclure cette information. À un
<b>certain</b> moment dans le futur, les machines commenceront à utiliser
cette liste mise à jour et refuseront d'exécuter les binaires vulnérables
avec Secure Boot.
@@ -132,8 +132,8 @@
<p>
La chronologie <i>exacte</i> du déploiement de ce changement n'est pas
-encore claire. Les fournisseurs de BIOS et UEFI vont inclure la nouvelle
-liste de révocation dans les constructions de microcode pour le matériel
+encore fixée. Les fournisseurs de BIOS et UEFI vont inclure la nouvelle
+liste de révocations dans les constructions de microcode pour le matériel
neuf à un certain moment. Microsoft <b>peut</b> aussi publier des mises
à jour pour des systèmes existants au moyen de Windows Update. Il est
possible que certaines distributions Linux fassent des mises à jour
@@ -165,7 +165,7 @@
<li>redémarrer en mode <q>rescue</q> en utilisant un
<a href="#buster_point_release">média d'installation récent</a> et
appliquer les mises à jour de cette manière ;</li>
- <li>ou désactiver temporairement l'amorçage de sécurité pour recouvrer un
+ <li>désactiver temporairement l'amorçage de sécurité pour recouvrer un
accès à la machine, appliquer les mises à jour puis le réactiver.</li>
</ul>
@@ -229,17 +229,17 @@
La série de bogues de « BootHole » marquait la première fois qu'une
révocation de clés à grande échelle était nécessaire dans l'écosystème
d'UEFI Secure Boot. Elle a démontré une malheureuse faiblesse de conception
-dans la révocation de SB : avec beaucoup de distributions Linux distinctes
-et beaucoup de binaires d'UEFI, la taille de la liste de révocation croit
+dans la révocation de SB : à cause du nombre de distributions Linux distinctes
+et de binaires d'UEFI, la taille de la liste de révocation croît
rapidement. De nombreux systèmes informatiques n'ont qu'un espace limité
-pour stocker les données de révocation de clés, et il peut se remplir très
+pour stocker les données de révocation de clés, pouvant se remplir très
rapidement et laisser ces systèmes cassés de diverses manières.
</p>
<p>
Pour lutter contre ce problème, les développeurs de shim ont conçu une
méthode beaucoup plus efficace en matière d'espace pour bloquer les
-binaires non sûres d'UEFI à l'avenir. Elle est nommée <b>SBAT</b>
+binaires non sûrs d'UEFI à l'avenir. Elle est nommée <b>SBAT</b>
(<q>Secure Boot Advanced Targeting</q>). Elle fonctionne en suivant les
numéros de création des programmes signés. Plutôt que de révoquer les
signatures individuellement quand des problèmes sont détectés, des
@@ -247,7 +247,7 @@
programmes ne sont plus considérées comme sûres. Révoquer une série
ancienne de binaires de GRUB2 (par exemple) devient maintenant un cas de
mise à jour d'une variable d'UEFI contenant le numéro de création de
-GRUB2 ; toute version du logiciel GRUB2 antérieur à ce numéro ne sera plus
+GRUB2 ; toute version du logiciel GRUB2 antérieure à ce numéro ne sera plus
considérée comme sûre. Pour plus d'informations sur SBAT, consultez la <a
href="https://github.com/rhboot/shim/blob/main/SBAT.md";>documentation de SBAT</a>
de shim.
@@ -255,7 +255,7 @@
<p>
<b>Malheureusement</b>, ce nouveau travail de développement de SBAT dans
-shim n'est pas encore tout à fait prêt. Les développeurs visaient à sortir
+shim n'est pas encore tout à fait prêt. Les développeurs visaient à publier
maintenant une version de shim avec cette nouvelle fonctionnalité majeure,
mais ils ont rencontré des difficultés inattendues. Le développement est
toujours en cours. Dans toute la communauté Linux, nous prévoyons de mettre
@@ -338,18 +338,18 @@
<h1><a name="buster_point_release">Version intermédiaire Debian 10.9 (<q>Buster</q>), médias d'installation et autonomes mis à jour</a></h1>
<p>
-Il a été prévu que tous les correctifs décrits ici soient inclus dans la
+Il est prévu que tous les correctifs décrits ici soient inclus dans la
version intermédiaire Debian 10.9 (<q>Buster</q>), qui doit être publiée
bientôt. Cette version 10.9 devrait donc être un bon choix pour les
utilisateurs qui recherchent des médias d'installation et autonomes. Les
-images plus anciennes peuvent cesser de fonctionner avec Secure Boot à
-l'avenir, lorsque les révocations seront déployées.
+images plus anciennes peuvent cesser de fonctionner avec Secure Boot
+à l'avenir, lorsque les révocations seront déployées.
</p>
<h1><a name="more_info">Plus d'informations</a></h1>
<p>
-Beaucoup plus d'informations sur la configuration de l'amorçage de sécurité
+Beaucoup plus d'informations sur la configuration de l'amorçage sécurisé
de Debian se trouvent dans le wiki de Debian — voir <a
href="https://wiki.debian.org/SecureBoot";>https://wiki.debian.org/SecureBoot</a>.
</p>
Reply to: