Re: [DONE] wml://security/2020-GRUB-UEFI-SecureBoot/index.wml

[Lev Lamberov <dogsleg@debian.org>]

Чт 30 июл 2020 @ 16:46 Galina Anikina <merilaga@yandex.ru>:

> On Thu, 2020-07-30 at 12:22 +0500, Lev Lamberov wrote:
>> --- english/security/2020-GRUB-UEFI-SecureBoot/index.wml	2020-
>> 07-30 12:15:24.222781416 +0500
>> +++ russian/security/2020-GRUB-UEFI-SecureBoot/index.wml	2020-
>> 07-30 12:16:07.209460839 +0500
>> @@ -1,23 +1,24 @@
>> -#use wml::debian::template title="GRUB2 UEFI SecureBoot
>> vulnerability - 'BootHole'"
>> +#use wml::debian::template title="Уязвимость GRUB2 UEFI SecureBoot
>> &mdash; 'BootHole'"
>> +#use wml::debian::translation-check
>> translation="a6a9e43990c1df5feef2155cce33d88befbe8993"
>> maintainer="Lev Lamberov"
>>  
>>  <p>
>> -Developers in Debian and elsewhere in the Linux community have
>> -recently become aware of a severe problem in the GRUB2 bootloader
>> that
>> -allows a bad actor to completely circumvent UEFI Secure Boot. The
>> full
>> -details of the problem are described
>> -in <a href="$(HOME)/security/2020/dsa-4735">Debian Security Advisory
>> -4735</a>. The aim of this document is to explain the consequences of
>> -this security vulnerability, and what steps have been taken to
>> address
>> -it.
>> +Разработчики Debian и других дистрибутивов сообщества Linux недавно
>> +узнали о серьёзной проблеме в загрузчике GRUB2, позволяющей
>> +злоумышленнику полностью обойти UEFI Secure Boot. Подробности
>> +касательно этой проблемы описаны в
>> +in <a href="$(HOME)/security/2020/dsa-4735">рекомендации по
>> безопасности Debian
>> +4735</a>. Цель настоящего документа состоит в объяснении последствий
>> +данной уязвимости, а также того, какие шаги следует предпринять для
>> её
>> +исправления.
>>  </p>
>>  
>>  <ul>
>> -  <li><b><a href="#what_is_SB">Background: What is UEFI Secure
>> Boot?</a></b></li>
>> -  <li><b><a href="#grub_bugs">Multiple GRUB2 bugs found</a></b></li>
>> -  <li><b><a href="#linux_bugs">Linux bugs found too</a></b></li>
>> -  <li><b><a href="#revocations">Key revocations needed to fix the
>> Secure Boot chain</a></b></li>
>> -  <li><b><a href="#revocation_problem">What are the effects of key
>> revocation?</a></b></li>
>> -  <li><b><a href="#package_updates">Updated packages</a></b></li>
>> +  <li><b><a href="#what_is_SB">Общая информация: что такое UEFI
>> Secure Boot?</a></b></li>
>> +  <li><b><a href="#grub_bugs">Обнаружение многочисленных ошибок
>> GRUB2</a></b></li>
>> +  <li><b><a href="#linux_bugs">Обнаружение ошибок Linux</a></b></li>
>> +  <li><b><a href="#revocations">Необходимости отзыва ключей для
>> исправления цепочки Secure Boot</a></b></li>
> может -
> "Необходимость в отзыве ключей..."
>
>
>> +  <li><b><a href="#revocation_problem">Каковы последствия отзыва
>> ключей?</a></b></li>
>> +  <li><b><a href="#package_updates">Обновлённые пакеты</a></b></li>
>>    <ul>
>>      <li><b><a href="#grub_updates">1. GRUB2</a></b></li>
>>      <li><b><a href="#linux_updates">2. Linux</a></b></li>
>> @@ -25,274 +26,272 @@
>>      <li><b><a href="#fwupdate_updates">4. Fwupdate</a></b></li>
>>      <li><b><a href="#fwupd_updates">5. Fwupd</a></b></li>
>>    </ul>
>> -  <li><b><a href="#buster_point_release">Debian 10.5 (<q>buster</q>)
>> -        point release, updated installation and live
>> -        media</a></b></li>
>> -  <li><b><a href="#more_info">More information</a></b></li>
>> +  <li><b><a href="#buster_point_release">Редакция Debian 10.5
>> (<q>buster</q>),
>> +        обновлённые установочные носители и <q>живые</q>
>> +        образы</a></b></li>
>> +  <li><b><a href="#more_info">Дополнительная информация</a></b></li>
>>  </ul>
>>  
>> -<h1><a name="what_is_SB">Background: What is UEFI Secure
>> Boot?</a></h1>
>> +<h1><a name="what_is_SB">Общая информация: что такое UEFI Secure
>> Boot?</a></h1>
>>  
>>  <p>
>> -UEFI Secure Boot (SB) is a verification mechanism for ensuring that
>> -code launched by a computer's UEFI firmware is trusted. It is
>> designed
>> -to protect a system against malicious code being loaded and executed
>> -early in the boot process, before the operating system has been
>> -loaded.
>> +UEFI Secure Boot (SB) представляет собой механизм проверки,
>> гарантирующий, что
>> +код, запущенный UEFI-микропрограммой компьютера, является
>> доверенным. 
>
> Может -
> UEFI Secure Boot (SB) представляет собой механизм проверки кода
> микропрограммы загрузки компьютера, гарантирующий что загружаются
> доверенные программы.
>
> Перед "что" вроде не везде ставятся запятые. А по общей фразе - мне
> кажется что так понятнее рядовому обывателю. :-))

Немного перефразировал:

UEFI Secure Boot (SB) представляет собой механизм проверки, гарантирующий что
запускаемый UEFI-микропрограммой компьютера код является доверенным.

>> Он разработан
>> +для защиты системы от вредоносного кода, загружаемого и исполняемого
>> +достаточно рано в процессе старта системы и до загрузки операционной
>> +системы.
>>  </p>
>>  
> может -
> "от вредоносного кода, который, в силу специфики выполнения своих
> функций, загружается и исполняется на самой ранней стадии загрузки
> системы, ещё до того, как могут активизироваться специальные
> программы."
>
> Да, опять, чуть отклонение от прямого перевода... :-))

Просто убрал двойное использование слова "система", остальное не стал
менять.

>>  <p>
>> -SB works using cryptographic checksums and signatures. Each
>> -program that is loaded by the firmware includes a signature and a
>> -checksum, and before allowing execution the firmware will verify
>> that
>> -the program is trusted by validating the checksum and the
>> -signature. When SB is enabled on a system, any attempt to execute an
>> -untrusted program will not be allowed. This stops unexpected /
>> -unauthorised code from running in the UEFI environment.
>> +SB работает с использованием криптографических контрольных сумм и
>> подписей. Каждая
>> +программа, загружаемая микропрограммой, содержит подпись и
>> контрольную сумму,
>
> Дважды звучит -
> "Каждая программа, загружаемая микропрограммой" 
> Может -
> Каждый блок кода, загружаемый микропрограммой, ...
> или
> Тот или иной блок кода, загружаемый микропрограммой, ...

"Блок кода" мне в этом контексте не нравится.

> А далее поставить точку и по тексту-
> Перед тем ...

ОК.

>> +перед тем, как разрешить исполнение, микропрограмма выполняет
>> проверку того, что
>> +запускаемая программа является доверенной. Это осуществляется путём
>> проверки контрольной
>> +суммы и подписи.. Если SB включён в системе, то любая попытка
>> выполнить
>> +недоверенную программу не будет разрешена. 
>
> Двойное "не- ... не" в предложении - сложно к восприятию -
> Может -
> Если SB включён в системе — то будет действовать запрет на выполнение
> любой недоверенной программы.

ОК, убрал двойное "не" и немного перефразировал:

Если SB включён в системе, то любая попытка выполнить недоверенную
программу будет запрещена.

>> Это позволяет предотвратить
>> +запуск непредусмотренного / неавторизованного кода в UEFI-окружении.
>>  </p>
>>  
>>  <p>
>> -Most x86 hardware comes from the factory pre-loaded with Microsoft
>> -keys. This means the firmware on these systems will trust binaries
>> -that are signed by Microsoft. Most modern systems will ship with SB
>> -enabled - they will not run any unsigned code by default, but it is
>> -possible to change the firmware configuration to either disable SB
>> or
>> -to enrol extra signing keys.
>> +Большинство оборудования с архитектурой x86 поставляется с завода с
>> предустановленными
>> +ключами Microsoft. Это означает, что микропрограмма в такой системе
>> доверяет двоичным
>> +файлам, подписанным Microsoft. Большинство современных систем
>> поставляются с включённым
>> +механизмом SB, по умолчанию они не запускают какой-либо
>> неподписанный код. Однако
>> +можно изменить настройки микропрограммы и либо отключить SB, либо
>> +зарегистрировать дополнительные ключи.
>>  </p>
>>  
>>  <p>
>> -Debian, like many other Linux-based operating systems, uses a
>> program
>> -called shim to extend that trust from the firmware to the other
>> -programs that we need to be secured during early boot: the GRUB2
>> -bootloader, the Linux kernel and firmware update tools (fwupd and
>> +Debian, как и многие другие операционные системы на основе Linux,
>> использует программу,
>> +называемую shim, для расширения доверия от микропрограммы до других
>> программам,
>> +которые нам требуется обезопасить в ходе ранней загрузки, это
>> загрузчик GRUB2,
>> +ядро Linux и инструменты обновления микропрограмм (fwupd и
>>  fwupdate).
>>  </p>
>>  
>
> Что-то здесь не так - :-))
>
> вот этот кусок надо как-то синхронизировать - множ. или единств. число
> - 
> "для расширения доверия от микропрограммы до других программам"
>
> А вот здесь "в ходе ранней загрузки, это" - может поставить тире?
> "в ходе ранней загрузки — это"
>
>> -<h1><a name="grub_bugs">Multiple GRUB2 bugs found</a></h1>
>> +<h1><a name="grub_bugs">Обнаружение многочисленных ошибок
>> GRUB2</a></h1>
>>  
>>  <p>
>> -Unfortunately, a serious bug has been found in the GRUB2 bootloader
>> -code which reads and parses its configuration (grub.cfg). This bug
>> -breaks the chain of trust; by exploiting this bug, it is possible to
>> -break out of the secured environment and load non-signed programs
>> -during early boot. This vulnerability was discovered by researchers
>> at
>> -Eclypsium and given the name
>> -<b><a href="
>> https://www.eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/";>BootHole</a></b>
>> ;.
>> +К сожалению, в коде загрузчика GRUB2 для чтения и грамматического
>> разбора
>> +файла настроек (grub.cfg) была обнаружена серьёзная ошибка, которая
>> +ломает цепочку доверия. Используя эту ошибку можно выйти из
>> защищённого
>> +окружения и загрузить неподписанные программы в ходе ранней
>> загрузки.
>> +Эта уязвимость была обнаружены исследователями Eclypsium и получила
>> +название <b><a href="
>> https://www.eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/";>BootHole</a></b>
>> ;.
>>  </p>
>>  
>>  <p>
>> -Instead of just fixing that one bug, developers have been prompted
>> to
>> -do an in-depth audit of GRUB2's source code. It would have been
>> -irresponsible to fix one major flaw without also looking for others!
>> A
>> -team of engineers have worked together for several weeks to identify
>> -and repair a range of further issues. We have found a few places
>> where
>> -internal memory allocations could overflow given unexpected inputs,
>> -several more places where integer overflow in math calculations
>> could
>> -cause trouble, and a few places where memory might be used after
>> -freeing it. Fixes for all of these have been shared and tested
>> across
>> -the community.
>> +Вместо исправления одной этой ошибки разработчики решили провести
>> +тщательный аудит исходного кода GRUB2. Было бы безответственно
>> +исправить одну серьёзную уязвимость без поиска других ошибок!
>> +Команда инженеров работала на протяжении нескольких недель над
>> определением
>
> может - 
> Команда инженеров на протяжении нескольких недель изучала и исправляла
> целый ряд проблем в исходном коде программы.

ОК, но "...работала над выявлением..."

>> +и исправлением целого ряда проблем. Мы обнаружили несколько мест,
>> где
>> +выделенные буферы внутренней памяти могут быть переполнены при
>> получении неожиданных
>> +входных данных, несколько место, где переполнение целых чисел в ходе
>
> входных данных, несколько мест, где переполнение
>
> о-лишнее
>
>> 
> математических
>> +вычислений может приводить к проблемам, а также несколько мест, где
>> память может
>> +использоваться после её освобождения. Исправления всех этих ошибок
>> были
>> +распространены между участниками сообщества и протестированы.
>>  </p>
>>  
>>  <p>
>> -Again, see <a href="$(HOME)/security/2020/dsa-4735">Debian Security
>> -Advisory 4735</a> for a full list of the issues found.
>> +Полный список проблем можно найти в <a
>> href="$(HOME)/security/2020/dsa-4735">рекомендации
>> +по безопасности Debian 4735</a>.
>>  </p>
>>  
>>  
>> -<h1><a name="linux_bugs">Linux bugs found too</a></h1>
>> +<h1><a name="linux_bugs">Обнаружение ошибок Linux</a></h1>
>>  
>>  <p>
>> -While discussing the GRUB2 flaws, developers also spoke about cases
>> -where Linux might also allow Secure Boot bypass. Two bugs were
>> -identified there, both allowing root to replace ACPI tables on a
>> -locked-down system when this should not be permitted. Fixes have
>> -already been released for those issues.
>> +В ходе обсуждения уязвимостей в GRUB2, разработчики говорили и о
>> случаях,
>> +когда ядро Linux может может позволить обойти Secure Boot. Были
>> обнаружены
>
> дважды "может может"
>
>> +две ошибки, обе позволяют суперпользователю заменить таблицы ACPI в
>> +заблокированной системе, когда это не должно быть разрешено.
>> Исправления
>> +этих проблем уже выпущены.
>>  </p>
>>  
>> -<h1><a name="revocations">Key revocations needed to fix the Secure
>> Boot chain</a></h1>
>> +<h1><a name="revocations">Необходимости отзыва ключей для
>> исправления цепочки Secure Boot</a></h1>
>>  
>
> Необходимость в отзыве ключей?
>
>>  <p>
>> -Debian and other operating system providers will obviously be <a
>> -href="#package_updates">releasing fixed versions</a> of GRUB2 and
>> -Linux. However, that cannot be a complete fix for the problems seen
>> -here. Malicious actors would still be able to use older vulnerable
>> -versions of each to be able to work around Secure Boot.
>> +Очевидно, Debian и другие поставщики операционных систем <a
>> +href="#package_updates">выпустят исправленные версии</a> GRUB2 и
>> +Linux. Тем не менее это не завершает исправление проблем.
>
> Может -
> на этом пока ещё не завершается исправление проблем?

Сделал так:
Тем не менее на этом исправление проблем не завершается.

>> +Злоумышленники всё ещё могут быть способны использовать предыдущие
>> уязвимые
>> +версии загрузчика и ядра, чтобы обойти Secure Boot.
>>  </p>
>>  
>>  <p>
>> -To stop that, the next step will be for Microsoft to blacklist those
>> -insecure binaries to stop them being run under SB. This is achieved
>> -using the <b>DBX</b> list, a feature of the UEFI Secure Boot
>> -design. All of the Linux distributions shipping with Microsoft-
>> signed
>> -copies of shim have been asked to provide details of the binaries or
>> -keys involved to facilitate this process. The <a
>> -href="https://uefi.org/revocationlistfile";>UEFI revocation list
>> -file</a> will be updated to include that information. At <b>some</b>
>> -future point, systems will start to use that updated list and will
>> -refuse to run the vulnerable binaries under Secure Boot.
>> +Для предотвращения этого следующим шагом будет внесение сотрудниками
>> Microsoft небезопасных
>> +двоичных файлов в список блокировки, чтобы они не могли быть
>> запущены при включённом SB.
>> +Это достигается с помощью списка <b>DBX</b>, который является частью
>> UEFI Secure Boot.
>> +Все дистрибутивы Linux, поставляющие подписанные Microsoft копии
>> shim,
>> +должны предоставить подробную информацию о двоичных файлах или
>> используемых ключах,
>> +чтобы указанные действия были выполнены. Будет обновлён <a
>> +href="https://uefi.org/revocationlistfile";>UEFI-файл со списком
>> отозванных ключей</a>,
>> +обновление будет содержат предоставленную информацию. 
>
> обновление будет содержатЬ
>
>> В <b>некоторый</b>
>> +момент в будущем системы начнут использовать этот обновлённый список
>> и перестанут
>> +запускать уязвимые двоичные файлы при использовании Secure Boot.
>>  </p>
>> 
>
>
> "В некоторый момент в будущем системы" -- "в ... в"
>
> Может -
> Чуть позднее, в некоторый момент времени, системы начнут использовать
> этот обновлённый список ... 
>
>
>>  
>>  <p>
>> -The <i>exact</i> timeline for that change being deployed is not yet
>> -clear. BIOS/UEFI vendors will include the new revocation list in new
>> -firmware builds for new hardware at some point. Microsoft <b>may</b>
>> -also issue updates to existing systems via Windows Update. Some
>> Linux
>> -distributions may issue updates via their own security updates
>> -process. Debian does not <b>yet</b> do this, but we are looking into
>> -it for the future.
>> +<i>Точный</i> срок развёртывания этого изменения пока не ясен.
>> +В какой-то момент поставщики BIOS/UEFI добавят новый список
>> отозванных ключей в новые сборки
>> +микропрограмм для нового оборудования. Microsoft <b>может</b>
>> +выпустить обновления для существующих систем через Windows Update.
>> Некоторые
>> +дистрибутивы Linux так же могут выпустить обновления через свои
>> собственные
>
> также могут
>
>
>> +системы обновления безопасности. Debian <b>пока</b> этого не сделал,
>> но мы
>> +собираемся сделать это в будущем.
>>  </p>
>>  
>
> Может -
> но мы собираемся сделать это в ближайшее время - такие "клише" сами
> выскакивают в голове иногда при прочтении того или иного отрывка
> текста 
> :-))

Там в оригинале не про ближайшее будущее. И даже с некоторой ноткой
сомнения.

>> -<h1><a name="revocation_problem">What are the effects of key
>> revocation?</a></h1>
>> +<h1><a name="revocation_problem">Каковы последствия отзыва
>> ключей?</a></h1>
>>  
>>  <p>
>> -Most vendors are wary about automatically applying updates which
>> -revoke keys used for Secure Boot. Existing SB-enabled software
>> -installations may suddenly refuse to boot altogether, unless the
>> user
>> -is careful to also install all the needed software updates as
>> -well. Dual-boot Windows/Linux systems may suddenly stop booting
>> -Linux. Old installation and live media will of course also fail to
>> -boot, potentially making it harder to recover systems.
>> +Большинство поставщиков с недоверием относятся к автоматическому
>> применению
>> +обновлений, которые отзывают ключи, используемые для Secure Boot.
>> Существующие
>> +наборы ПО могут неожиданно перестать загружаться при включённом SB,
>> если
>> +пользователь также не установил требуемые обновления ПО. Двойная
>> +загрузка систем Windows/Linux тоже может неожиданное прекратить
>> загрузку
>> +Linux. 
>
> тоже может неожиданно
>
> "е" - лишнее
>
>
>> Конечно же, старые установочные образы и <q>живые</q> тоже перестанут
>> +загружаться, что потенциально усложнит восстановление систем.
>>  </p>
>>  
>>  <p>
>> -There are two obvious ways to fix a non-booting system like this:
>> +Имеются два очевидных способа исправления незагружающейся системы:
>>  </p>
>>  
>>  <ul>
>> -  <li>Reboot into <q>rescue</q> mode
>> -    using <a href="#buster_point_release">newer installation
>> media</a>, and
>> -    apply the needed updates that way; or</li>
>> -  <li>Temporarily disable Secure Boot to regain access to the
>> system,
>> -    apply updates then re-enable it.</li>
>> +  <li>Перезагрузиться в режиме <q>восстановления</q>,
>> +    используя <a href="#buster_point_release">более новые
>> установочные носители</a>,
>> +    и применить необходимые обновления; или</li>
>> +  <li>Временно отключить Secure Boot для получения доступа к
>> системе,
>> +    применить обновления, а затем заново включить SB.</li>
>>  </ul>
>>  
>>  <p>
>> -These may both sound like simple options, but each could be very
>> -time-consuming for users with multiple systems. Also be aware that
>> -enabling or disabling Secure Boot needs direct machine access, by
>> -design. It is normally <b>not</b> possible to change that
>> -configuration outside of the computer's firmware setup. Remote
>> server
>> -machines may need special care here for exactly this reason.
>> +Оба пути могут казаться простыми, но каждый из них может отнять у
>> пользователей
>> +нескольких систем время. 
>
> Может - 
> Оба эти пути могут показаться вначале простыми, однако каждый из них
> потребует определённого количества времени пользователя, особенно если
> у него имеются в наличии несколько систем.

Сделал так:
Оба пути могут вначале показаться простыми, однако каждый из них потребует
некоторого количества времени, особенно от пользователей нескольких систем.

>> Кроме того, помните, что для включения или отключения
>> +Secure Boot требуется непосредственный доступ к машине. Обычно
>> +<b>нельзя</b> изменить эту настройку извне системы настройки
>> микропрграммы
>
> микропрОграммы
>
>> +компьютера. Удалённые серверные машины могут потребовать
>> специального
>> +обращения по этой самой причине.
>>  </p>
>>  
>>  <p>
>> -For these reasons, it is strongly recommended that <b>all</b> Debian
>> -users be careful to install all
>> -the <a href="#package_updates">recommended updates</a> for their
>> -systems as soon as possible, to reduce the chances of problems in
>> -future.
>> +По этим причинам настоятельно рекомендуется, чтобы <b>все</b>
>> пользователи
>> +Debian установили все <a href="#package_updates">рекомендованные
>> обновления</a> для
>> +своих систем как можно скорее. Это позволит снизить вероятность
>> возникновения
>> +проблем в будущем.
>>  </p>
>>  
>> -<h1><a name="package_updates">Updated packages</a></h1>
>> +<h1><a name="package_updates">Обновлённые пакеты</a></h1>
>>  
>>  <p>
>> -<b>Note:</b> Systems running Debian 9 (<q>stretch</q>) and older
>> -will <b>not</b> necessarily receive updates here, as Debian 10
>> -(<q>buster</q>) was the first Debian release to include support for
>> UEFI
>> +<b>ВНИМАНИЕ:</b> системы, использующие Debian 9 (<q>stretch</q>) и
>> более ранние
>> +выпуски <b>необязательно</b> получат соответствующие обновления,
>> поскольку Debian 10
>> +(<q>buster</q>) является первым выпуском Debian, включающим
>> поддержку UEFI
>>  Secure Boot.
>>  </p>
>>  
>> -<p>The signed versions of all packages here have been updated, even
>> if
>> -no other changes were needed. Debian has had to generate a new
>> signing
>> -key/certificate for its own Secure Boot packages. The old
>> certificate
>> -was labelled <q>Debian Secure Boot Signer</q> (fingerprint
>> +<p>Были обновлены подписанные версии всех пакетов, даже если никакие
>> +другие изменения не требовались. Debian пришлось создать новый
>> ключ/сертификат
>> +для подписывания собственных пакетов, поддерживающих Secure Boot.
>> Старый сертификат
>> +был помечен как <q>Debian Secure Boot Signer</q> (отпечаток ключа
>>  <code>f156d24f5d4e775da0e6a9111f074cfce701939d688c64dba093f97753434f
>> 2c</code>);
>> -the new certificate is <q>Debian Secure Boot Signer 2020</q>
>> +новый сертификат помечен как <q>Debian Secure Boot Signer 2020</q>
>>  (<code>3a91a54f9f46a720fe5bbd2390538ba557da0c2ed5286f5351fe04fff254e
>> c31</code>). </p>
>>  
>>  <p>
>> -There are five source packages in Debian that will be updated due to
>> -the UEFI Secure Boot changes described here:
>> +В Debian имеются пять пакетов с исходным кодом, которые будут
>> обновлены
>> +в связи с изменениями UEFI Secure Boot:
>>  </p>
>>  
>>  <h2><a name="grub_updates">1. GRUB2</a></h2>
>>  
>>  <p>
>> -Updated versions of Debian's GRUB2 packages are available now via
>> the
>> -debian-security archive for the stable Debian 10 release
>> -(<q>buster</q>). Fixed versions will be in the normal Debian archive
>> -for development versions of Debian (unstable and testing) very soon.
>> +Обновлённые версии Debian-пакетов GRUB2 доступны уже сейчас в архиве
>> +debian-security для стабильного выпуска Debian 10
>> +(<q>buster</q>). Исправленные версии очень скоро появятся в обычном
>> архиве Debian
>> +для разрабатываемых версий Debian (нестабильного и тестируемого).
>>  </p>
>>  
>>  <h2><a name="linux_updates">2. Linux</a></h2>
>>  
>>  <p>
>> -Updated versions of Debian's linux packages are available now via
>> -buster-proposed-updates for the stable Debian 10 (<q>buster</q>)
>> -release and will be included with the upcoming 10.5 point
>> -release. New packages are also in the Debian archive for development
>> -versions of Debian (unstable and testing). We hope to have fixed
>> -packages uploaded for buster-backports soon also.
>> +Обновлённые версии Debian-пакетов linux доступны уже сейчас через
>> +buster-proposed-updates для стабильного выпуска Debian 10
>> (<q>buster</q>)
>> +и будут включены в готовящуюся редакцию 10.5. Новые пакеты
>> +также находятся в архиве Debian для разрабатываемых версий
>> +Debian (нестабильного и тестируемого). Мы надеемся, что исправленные
>> пакеты
>> +будут вскоре загружены в buster-backports.
>>  </p>
>>  
>>  <h2><a name="shim_updates">3. Shim</a></h2>
>>  
>>  <p>
>> -Due to the way that Debian's Secure Boot key management works,
>> Debian
>> -does <b>not</b> need to revoke its existing Microsoft-signed shim
>> -packages. However, the signed versions of the shim-helper packages
>> -needed rebuilding to use the new signing key.
>> +В связи с тем, как устроено управления ключами Secure Boot в Debian,
>> Debian
>> +<b>не</b> требуется отзывать существующие и подписанные Microsoft
>> +пакеты shim. Тем не менее подписанные версии пакетов shim-helper
>> +необходимо собрать заново с использованием нового ключа.
>>  </p>
>>  
>
> Вот это -
> "В связи с тем, как устроено управления ключами Secure Boot в
> Debian..."
> может так -
> "Учитывая механизм управления ключами Secure Boot в Debian..."
>
>>  <p>
>> -Updated versions of Debian's shim packages are available now via
>> -buster-proposed-updates for the stable Debian 10 (<q>buster</q>)
>> -release and will be included with the upcoming 10.5 point
>> -release. New packages are also in the Debian archive for development
>> -versions of Debian (unstable and testing).
>> +Обновлённые версии Debian-пакетов shim доступны уже сейчас через
>> +buster-proposed-updates для стабильного выпуска Debian 10
>> (<q>buster</q>)
>> +и будут включены в готовящуюся редакцию 10.5. Новые пакеты
>> +также находятся в архиве Debian для разрабатываемых версий
>> +Debian (нестабильного и тестируемого).
>>  </p>
>>  
>>  <h2><a name="fwupdate_updates">4. Fwupdate</a></h2>
>>  
>>  <p>
>> -Updated versions of Debian's fwupdate packages are available now via
>> -buster-proposed-updates for the stable Debian 10 (<q>buster</q>)
>> -release and will be included with the upcoming 10.5 point
>> -release. fwupdate had already been removed from unstable and testing
>> -a while ago in favour of fwupd.
>> +Обновлённые версии Debian-пакетов fwupdate доступны уже сейчас через
>> +buster-proposed-updates для стабильного выпуска Debian 10
>> (<q>buster</q>)
>> +и будут включены в готовящуюся редакцию 10.5. Пакет fwupdate уже был
>> +удалён из нестабильного и тестируемого выпусков в связи с его
>> заменой
>> +на пакет fwupd.
>>  </p>
>>  
>>  <h2><a name="fwupd_updates">5. Fwupd</a></h2>
>>  
>>  <p>
>> -Updated versions of Debian's fwupd packages are available now via
>> -buster-proposed-updates for the stable Debian 10 (<q>buster</q>)
>> -release and will be included with the upcoming 10.5 point
>> -release. New packages are also in the Debian archive for development
>> -versions of Debian (unstable and testing).
>> +Обновлённые версии Debian-пакетов fwupd доступны уже сейчас через
>> +buster-proposed-updates для стабильного выпуска Debian 10
>> (<q>buster</q>)
>> +и будут включены в готовящуюся редакцию 10.5. Новые пакеты
>> +также находятся в архиве Debian для разрабатываемых версий
>> +Debian (нестабильного и тестируемого).
>>  </p>
>>  
>> -<h1><a name="buster_point_release">Debian 10.5 (<q>buster</q>) point
>> -release, updated installation and live media</a></h1>
>> +<h1><a name="buster_point_release">Редакция Debian 10.5
>> (<q>buster</q>),
>> +обновлённые установочные носители и <q>живые</q> образы</a></h1>
>>  
>>  <p>
>> -All of the fixes described here are targeted for inclusion in the
>> -Debian 10.5 (<q>buster</q>) point release, due for release on 1st
>> -August 2020. 10.5 would therefore be a good choice for users looking
>> -for Debian installation and live media. Earlier images may not work
>> -with Secure Boot in future as revocations roll out.
>> +Все описанные здесь обновления планируется включить в редакцию
>> +Debian 10.5 (<q>buster</q>), который будет выпущен 1 августа 2020
>> года.
>> +Таким образом, пользователям, которым нужны установочные и
>> <q>живые</q>
>> +образы Debian следует выбирать 10.5. В будущем более ранние образы
>> могут
>> +не работать с Secure Boot, так как будет выполнен отзыв ключей.
>>  </p>
>>  
>> -<h1><a name="more_info">More information</a></h1>
>> +<h1><a name="more_info">Дополнительная информация</a></h1>
>>  
>>  <p>
>> -Much more information about Debian's UEFI Secure Boot setup is in
>> the
>> -Debian wiki -
>> -see <a href="
>> https://wiki.debian.org/SecureBoot";>https://wiki.debian.org/SecureBoot</a>.</p
>> >
>> +Дополнительную информацию о настройке UEFI Secure Boot в Debian
>> +можно найти в вики Debian по адресу <a href="
>> https://wiki.debian.org/SecureBoot";>\
>> +https://wiki.debian.org/SecureBoot</a>.</p>
>>  
>>  <p>
>> -Other resources on this topic include:
>> +Другие ресурсы по данной теме:
>>  </p>
>>  
>>  <ul>
>> -  <li><a href="
>> https://www.eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/";>Eclypsium
>> -      <q>BootHole</q> article</a> describing the weaknesses
>> found</li>
>> -  <li><a href="
>> https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV200011";>Microsoft
>> -      Guidance for Addressing Security Feature Bypass in
>> GRUB</a></li>
>> -  <li><a href="
>> https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/GRUB2SecureBootBypass";>Ubuntu
>> -      KnowledgeBase article</a></li>
>> -  <li><a href="
>> https://access.redhat.com/security/vulnerabilities/grub2bootloader";>Red
>> -      Hat vulnerability article</a></li>
>> -  <li><a href="
>> https://www.suse.com/c/suse-addresses-grub2-secure-boot-issue/";>SUSE
>> -      vulnerability article</a></li>
>> +  <li><a href="
>> https://www.eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/";>Статья
>> Eclypsium
>> +      <q>BootHole</q></a>, описывающая обнаруженные уязвимости</li>
>> +  <li><a href="
>> https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV200011";>Руководство
>> +      Microsoft под решению пробем обхода безопасности в
>> GRUB</a></li>
>
> что-то надо исправить здесь... 
> Может - 
> по решению проблем?

Да. Спасибо!