Repository : http://git.fedorahosted.org/git/?p=docs/uefi-secure-boot-guide.git
On branch : master
>---------------------------------------------------------------
commit f5c1b2f8541d59acf7e660d309dfdaf72db7d84b
Author: Eric Christensen <sparks(a)redhat.com>
Date: Thu Jan 31 14:53:55 2013 -0500
Added explaination of pesign
>---------------------------------------------------------------
en-US/Tools.xml | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/en-US/Tools.xml b/en-US/Tools.xml
index 244652c..c9d6854 100644
--- a/en-US/Tools.xml
+++ b/en-US/Tools.xml
@@ -11,12 +11,13 @@
<section id="sect-UEFI_Secure_Boot_Guide-Tools-shim">
<title>Shim</title>
<para>
- Shim is the cryptographically signed software that creates the trust between the UEFI firmware and GRUB and the kernel software. Shim is cryptographically signed by Verisign (via Microsoft) so that the UEFI firmware will cryptographically recognize the &PRODUCT; system and allow the software to continue through the boot process. The shim validates GRUB and kernel though a cryptographic verification based on a &PRODUCT; key used to sign all three.
+ <firstterm>Shim</firstterm> is the cryptographically signed software that creates the trust between the UEFI firmware and GRUB and the kernel software. Shim is cryptographically signed by Verisign (via Microsoft) so that the UEFI firmware will cryptographically recognize the &PRODUCT; system and allow the software to continue through the boot process. The shim validates GRUB and kernel though a cryptographic verification based on a &PRODUCT; key used to sign all three.
</para>
</section>
<section id="sect-UEFI_Secure_Boot_Guide-Tools-pesign">
<title>pesign</title>
<para>
+ <firstterm>Pesign</firstterm> allows users to create their own shim and use their own cryptographic keys. Using this tool, one can create their own trust model and not be required to trust the Microsoft keys and trust model. Once the user has created their keys and signed their shim, and optionally signed and built GRUB and kernel, they can use the setup mode in the firmware to install &PRODUCT; and use the <firstterm>sbsetup</firstterm> tool as provided by pesign to enroll their keys in the firmware.
</para>
</section>
<section id="sect-UEFI_Secure_Boot_Guide-Tools-efikeygen">
Repository : http://git.fedorahosted.org/git/?p=docs/uefi-secure-boot-guide.git
On branch : master
>---------------------------------------------------------------
commit 7853c734e91a9e9cca5275c5a75339e6b0ba5dbd
Author: Eric Christensen <sparks(a)redhat.com>
Date: Thu Jan 31 14:42:11 2013 -0500
Added explaination of shim
>---------------------------------------------------------------
en-US/Tools.xml | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/en-US/Tools.xml b/en-US/Tools.xml
index 47dfe06..244652c 100644
--- a/en-US/Tools.xml
+++ b/en-US/Tools.xml
@@ -11,6 +11,7 @@
<section id="sect-UEFI_Secure_Boot_Guide-Tools-shim">
<title>Shim</title>
<para>
+ Shim is the cryptographically signed software that creates the trust between the UEFI firmware and GRUB and the kernel software. Shim is cryptographically signed by Verisign (via Microsoft) so that the UEFI firmware will cryptographically recognize the &PRODUCT; system and allow the software to continue through the boot process. The shim validates GRUB and kernel though a cryptographic verification based on a &PRODUCT; key used to sign all three.
</para>
</section>
<section id="sect-UEFI_Secure_Boot_Guide-Tools-pesign">
Repository : http://git.fedorahosted.org/git/?p=docs/uefi-secure-boot-guide.git
On branch : master
>---------------------------------------------------------------
commit 5917d3bd34dff2e8bcf7b372403c15a2f5246875
Author: Eric Christensen <sparks(a)redhat.com>
Date: Thu Jan 31 14:15:34 2013 -0500
Changed wording around 'malware' being present
>---------------------------------------------------------------
en-US/What_is_Secure_Boot.xml | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/en-US/What_is_Secure_Boot.xml b/en-US/What_is_Secure_Boot.xml
index 1cb0b84..b13206e 100644
--- a/en-US/What_is_Secure_Boot.xml
+++ b/en-US/What_is_Secure_Boot.xml
@@ -28,7 +28,7 @@ outside of the concept of Secure Boot and into another topic.
&PRODUCT; has expanded the chain of trust into the Kernel.
Verification happens as far as only loading signed kernel modules, but it
does not extend to user space applications. We can be certain that no
-malware is present until the initial ramdisk (initrd) is loaded. Since
+unsigned executable code is present until the initial ramdisk (initrd) is loaded. Since
initrd cannot currently be signed, it cannot be verified.
</para>
</section>
Repository : http://git.fedorahosted.org/git/?p=docs/uefi-secure-boot-guide.git
On branch : master
>---------------------------------------------------------------
commit 49b6425177f62dba877ccb5e5dd3f2c35fe0b529
Author: Eric Christensen <sparks(a)redhat.com>
Date: Thu Jan 31 11:52:06 2013 -0500
Replaced 'Fedora' with entity
>---------------------------------------------------------------
en-US/Implementation_of_Secure_Boot.xml | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/en-US/Implementation_of_Secure_Boot.xml b/en-US/Implementation_of_Secure_Boot.xml
index a95d414..4a52ca0 100644
--- a/en-US/Implementation_of_Secure_Boot.xml
+++ b/en-US/Implementation_of_Secure_Boot.xml
@@ -6,16 +6,16 @@
<chapter id="chap-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot">
<title>&PRODUCT;'s Implementation of UEFI Secure Boot</title>
<para>
- The Fedora Secure Boot implementation includes support for two methods of booting under the Secure Boot mechanism. The first method utilizes the signing service hosted by Microsoft to provide a copy of the shim bootloader signed with the Microsoft keys. The second method is a more general form of the first, wherein a site or user can create their own keys, deploy them in system firmware, and sign their own binaries.
+ The &PRODUCT; Secure Boot implementation includes support for two methods of booting under the Secure Boot mechanism. The first method utilizes the signing service hosted by Microsoft to provide a copy of the shim bootloader signed with the Microsoft keys. The second method is a more general form of the first, wherein a site or user can create their own keys, deploy them in system firmware, and sign their own binaries.
</para>
<section id="sect-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot-Keys">
<title>The Keys</title>
<para>
The solution to use the Microsoft signing service was one of
simplicity. The key Microsoft uses is shipped on all known hardware, which
-should result in Fedora being able to boot on this hardware without issue.
+should result in &PRODUCT; being able to boot on this hardware without issue.
There are of course risks having to rely on a third party for this service.
-Fedora is committed to closely watching activity in this space and will
+&PROJECT; is committed to closely watching activity in this space and will
respond to any new information appropriately.
</para>
</section>
@@ -24,7 +24,7 @@ respond to any new information appropriately.
<para>
The shim package also contains a blacklist of known bad keys or
binaries that should not be allowed to boot. Microsoft will provide this
-list to Fedora for inclusion. This may create periodic update to the
+list to &PROJECT; for inclusion. This may create periodic update to the
shim-signed package that do not change the actual shim binary, but will
update the blacklist to ensure known bad code cannot be executed.
</para>
@@ -32,7 +32,7 @@ update the blacklist to ensure known bad code cannot be executed.
In both methods, shim, grub2, and the kernel will detect that they
are started in what UEFI describes as "User mode" with Secure Boot enabled,
and upon detecting this they will validate the next stage with a
-Fedora-specific cryptographic public key before starting it. The validation
+&PRODUCT;-specific cryptographic public key before starting it. The validation
is done via shim for grub2, and grub2 calls back to shim to validate the
kernel as well. Once the kernel is booted, it will also detect that it is
in Secure Boot mode, which will cause several things to be true:
Repository : http://git.fedorahosted.org/git/?p=docs/uefi-secure-boot-guide.git
On branch : master
>---------------------------------------------------------------
commit 738de1f29c227306fcf751dd145192b4f50cec3f
Author: Eric Christensen <sparks(a)redhat.com>
Date: Thu Jan 31 11:48:39 2013 -0500
Fixed spelling error
>---------------------------------------------------------------
en-US/Implementation_of_Secure_Boot.xml | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/en-US/Implementation_of_Secure_Boot.xml b/en-US/Implementation_of_Secure_Boot.xml
index 757f7ff..a95d414 100644
--- a/en-US/Implementation_of_Secure_Boot.xml
+++ b/en-US/Implementation_of_Secure_Boot.xml
@@ -14,7 +14,7 @@
The solution to use the Microsoft signing service was one of
simplicity. The key Microsoft uses is shipped on all known hardware, which
should result in Fedora being able to boot on this hardware without issue.
-There are fo course risks having to rely on a third party for this service.
+There are of course risks having to rely on a third party for this service.
Fedora is committed to closely watching activity in this space and will
respond to any new information appropriately.
</para>
Repository : http://git.fedorahosted.org/git/?p=docs/uefi-secure-boot-guide.git
On branch : master
>---------------------------------------------------------------
commit f95d7399c4304fdb5a1d4889fded887e608474bd
Author: Josh Bressers <josh(a)bress.net>
Date: Thu Jan 31 10:10:38 2013 -0600
Add notes about the implementation (shim, keys, and a note about the key expiration)
Signed-off-by: Eric Christensen <sparks(a)redhat.com>
>---------------------------------------------------------------
en-US/Implementation_of_Secure_Boot.xml | 60 ++++++++++++++++++++++++++----
1 files changed, 52 insertions(+), 8 deletions(-)
diff --git a/en-US/Implementation_of_Secure_Boot.xml b/en-US/Implementation_of_Secure_Boot.xml
index 013cb7a..757f7ff 100644
--- a/en-US/Implementation_of_Secure_Boot.xml
+++ b/en-US/Implementation_of_Secure_Boot.xml
@@ -8,15 +8,44 @@
<para>
The Fedora Secure Boot implementation includes support for two methods of booting under the Secure Boot mechanism. The first method utilizes the signing service hosted by Microsoft to provide a copy of the shim bootloader signed with the Microsoft keys. The second method is a more general form of the first, wherein a site or user can create their own keys, deploy them in system firmware, and sign their own binaries.
</para>
- <para>
- In both methods, shim, grub2, and the kernel will detect that they are started in what UEFI describes as "User mode" with Secure Boot enabled, and upon detecting this they will validate the next stage with a Fedora-specific cryptographic public key before starting it. The validation is done via shim for grub2, and grub2 calls back to shim to validate the kernel as well. Once the kernel is booted, it will also detect that it is in Secure Boot mode, which will cause several things to be true:
+ <section id="sect-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot-Keys">
+ <title>The Keys</title>
+ <para>
+ The solution to use the Microsoft signing service was one of
+simplicity. The key Microsoft uses is shipped on all known hardware, which
+should result in Fedora being able to boot on this hardware without issue.
+There are fo course risks having to rely on a third party for this service.
+Fedora is committed to closely watching activity in this space and will
+respond to any new information appropriately.
+ </para>
+ </section>
+ <section id="sect-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot-Shim">
+ <title>The Shim</title>
+ <para>
+ The shim package also contains a blacklist of known bad keys or
+binaries that should not be allowed to boot. Microsoft will provide this
+list to Fedora for inclusion. This may create periodic update to the
+shim-signed package that do not change the actual shim binary, but will
+update the blacklist to ensure known bad code cannot be executed.
+ </para>
+ <para>
+ In both methods, shim, grub2, and the kernel will detect that they
+are started in what UEFI describes as "User mode" with Secure Boot enabled,
+and upon detecting this they will validate the next stage with a
+Fedora-specific cryptographic public key before starting it. The validation
+is done via shim for grub2, and grub2 calls back to shim to validate the
+kernel as well. Once the kernel is booted, it will also detect that it is
+in Secure Boot mode, which will cause several things to be true:
<simplelist>
<member>it will validate the boot command line to only allow certain kernel settings</member>
<member>it will check modules at load time for signatures and refuse to load them if they are unsigned or signed with a signature not found in the UEFI key store variables (see note)</member>
<member>it will refuse any operations from userland which cause userland-defined DMA.</member>
</simplelist>
- </para>
- <para>
+ </para>
+ </section>
+ <section id="sect-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot-Restrictions">
+ <title>Restrictions</title>
+ <para>
These restrictions are in place to be fully compliant with Secure Boot. This requires us to prevent any execution of unverified code at the supervisor level. Most users won't notice these restrictions as most of the userspace packages that required such access have been fixed to work without it. However, there are a few services or features that will not work in a Secure Boot enabled machine at this time. They include:
<simplelist>
<member>kexec/kdump</member>
@@ -24,14 +53,29 @@
<member>third party modules that are unsigned, or signed with an unknown key</member>
<member>systemtap kernel probing (and kprobes)</member>
</simplelist>
- </para>
- <para>
- In future iterations of Secure Boot support the above may also be possible, however secure implementations were not feasible in the Fedora 18 timeframe.
- </para>
+ </para>
+ <para>
+ In future iterations of Secure Boot support the above may also be
+possible, however secure implementations were not feasible in the Fedora 18
+timeframe. If you require support of any of these featurs, Secure Boot must
+be disabled.
+ </para>
<note>
<title>Note</title>
<para>Other distributions have chosen to not require signed kernel modules in their Secure Boot implementation. Fedora believes that to fully support Secure Boot this is required. We are working to limit the impacts of this while ensuring that untrusted module code is not allowed to execute.
</para>
</note>
+ <important>
+ <title>Important</title>
+ <para>
+ Currently, the Fedora shim was signed in a way that gives it an
+expiration date of October 2013, prior to the Fedora 18 end-of-life. We are
+not aware of any hardware that honors this expiration date, but it's not
+out of the question. This is the date Microsoft gave the signature, Fedora
+has no control over it. We are investigating this issue and expect to
+resolve it in the future.
+ </para>
+ </important>
+ </section>
</chapter>
Repository : http://git.fedorahosted.org/git/?p=docs/uefi-secure-boot-guide.git
On branch : master
>---------------------------------------------------------------
commit e109619b9555b4637e6e0d35019a68a9a5ba0742
Author: Eric Christensen <sparks(a)redhat.com>
Date: Thu Jan 31 11:45:21 2013 -0500
Revert "Add notes about the implementation (shim, keys, and a note about the key expiration)"
This reverts commit 0a5bf21c85e84a8f11d531b9128902c4c4b98105.
>---------------------------------------------------------------
en-US/Implementation_of_Secure_Boot.xml | 60 ++++--------------------------
1 files changed, 8 insertions(+), 52 deletions(-)
diff --git a/en-US/Implementation_of_Secure_Boot.xml b/en-US/Implementation_of_Secure_Boot.xml
index 757f7ff..013cb7a 100644
--- a/en-US/Implementation_of_Secure_Boot.xml
+++ b/en-US/Implementation_of_Secure_Boot.xml
@@ -8,44 +8,15 @@
<para>
The Fedora Secure Boot implementation includes support for two methods of booting under the Secure Boot mechanism. The first method utilizes the signing service hosted by Microsoft to provide a copy of the shim bootloader signed with the Microsoft keys. The second method is a more general form of the first, wherein a site or user can create their own keys, deploy them in system firmware, and sign their own binaries.
</para>
- <section id="sect-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot-Keys">
- <title>The Keys</title>
- <para>
- The solution to use the Microsoft signing service was one of
-simplicity. The key Microsoft uses is shipped on all known hardware, which
-should result in Fedora being able to boot on this hardware without issue.
-There are fo course risks having to rely on a third party for this service.
-Fedora is committed to closely watching activity in this space and will
-respond to any new information appropriately.
- </para>
- </section>
- <section id="sect-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot-Shim">
- <title>The Shim</title>
- <para>
- The shim package also contains a blacklist of known bad keys or
-binaries that should not be allowed to boot. Microsoft will provide this
-list to Fedora for inclusion. This may create periodic update to the
-shim-signed package that do not change the actual shim binary, but will
-update the blacklist to ensure known bad code cannot be executed.
- </para>
- <para>
- In both methods, shim, grub2, and the kernel will detect that they
-are started in what UEFI describes as "User mode" with Secure Boot enabled,
-and upon detecting this they will validate the next stage with a
-Fedora-specific cryptographic public key before starting it. The validation
-is done via shim for grub2, and grub2 calls back to shim to validate the
-kernel as well. Once the kernel is booted, it will also detect that it is
-in Secure Boot mode, which will cause several things to be true:
+ <para>
+ In both methods, shim, grub2, and the kernel will detect that they are started in what UEFI describes as "User mode" with Secure Boot enabled, and upon detecting this they will validate the next stage with a Fedora-specific cryptographic public key before starting it. The validation is done via shim for grub2, and grub2 calls back to shim to validate the kernel as well. Once the kernel is booted, it will also detect that it is in Secure Boot mode, which will cause several things to be true:
<simplelist>
<member>it will validate the boot command line to only allow certain kernel settings</member>
<member>it will check modules at load time for signatures and refuse to load them if they are unsigned or signed with a signature not found in the UEFI key store variables (see note)</member>
<member>it will refuse any operations from userland which cause userland-defined DMA.</member>
</simplelist>
- </para>
- </section>
- <section id="sect-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot-Restrictions">
- <title>Restrictions</title>
- <para>
+ </para>
+ <para>
These restrictions are in place to be fully compliant with Secure Boot. This requires us to prevent any execution of unverified code at the supervisor level. Most users won't notice these restrictions as most of the userspace packages that required such access have been fixed to work without it. However, there are a few services or features that will not work in a Secure Boot enabled machine at this time. They include:
<simplelist>
<member>kexec/kdump</member>
@@ -53,29 +24,14 @@ in Secure Boot mode, which will cause several things to be true:
<member>third party modules that are unsigned, or signed with an unknown key</member>
<member>systemtap kernel probing (and kprobes)</member>
</simplelist>
- </para>
- <para>
- In future iterations of Secure Boot support the above may also be
-possible, however secure implementations were not feasible in the Fedora 18
-timeframe. If you require support of any of these featurs, Secure Boot must
-be disabled.
- </para>
+ </para>
+ <para>
+ In future iterations of Secure Boot support the above may also be possible, however secure implementations were not feasible in the Fedora 18 timeframe.
+ </para>
<note>
<title>Note</title>
<para>Other distributions have chosen to not require signed kernel modules in their Secure Boot implementation. Fedora believes that to fully support Secure Boot this is required. We are working to limit the impacts of this while ensuring that untrusted module code is not allowed to execute.
</para>
</note>
- <important>
- <title>Important</title>
- <para>
- Currently, the Fedora shim was signed in a way that gives it an
-expiration date of October 2013, prior to the Fedora 18 end-of-life. We are
-not aware of any hardware that honors this expiration date, but it's not
-out of the question. This is the date Microsoft gave the signature, Fedora
-has no control over it. We are investigating this issue and expect to
-resolve it in the future.
- </para>
- </important>
- </section>
</chapter>
Repository : http://git.fedorahosted.org/git/?p=docs/uefi-secure-boot-guide.git
On branch : master
>---------------------------------------------------------------
commit 0a5bf21c85e84a8f11d531b9128902c4c4b98105
Author: Josh Bressers <josh(a)bress.net>
Date: Thu Jan 31 10:10:38 2013 -0600
Add notes about the implementation (shim, keys, and a note about the key expiration)
>---------------------------------------------------------------
en-US/Implementation_of_Secure_Boot.xml | 60 ++++++++++++++++++++++++++----
1 files changed, 52 insertions(+), 8 deletions(-)
diff --git a/en-US/Implementation_of_Secure_Boot.xml b/en-US/Implementation_of_Secure_Boot.xml
index 013cb7a..757f7ff 100644
--- a/en-US/Implementation_of_Secure_Boot.xml
+++ b/en-US/Implementation_of_Secure_Boot.xml
@@ -8,15 +8,44 @@
<para>
The Fedora Secure Boot implementation includes support for two methods of booting under the Secure Boot mechanism. The first method utilizes the signing service hosted by Microsoft to provide a copy of the shim bootloader signed with the Microsoft keys. The second method is a more general form of the first, wherein a site or user can create their own keys, deploy them in system firmware, and sign their own binaries.
</para>
- <para>
- In both methods, shim, grub2, and the kernel will detect that they are started in what UEFI describes as "User mode" with Secure Boot enabled, and upon detecting this they will validate the next stage with a Fedora-specific cryptographic public key before starting it. The validation is done via shim for grub2, and grub2 calls back to shim to validate the kernel as well. Once the kernel is booted, it will also detect that it is in Secure Boot mode, which will cause several things to be true:
+ <section id="sect-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot-Keys">
+ <title>The Keys</title>
+ <para>
+ The solution to use the Microsoft signing service was one of
+simplicity. The key Microsoft uses is shipped on all known hardware, which
+should result in Fedora being able to boot on this hardware without issue.
+There are fo course risks having to rely on a third party for this service.
+Fedora is committed to closely watching activity in this space and will
+respond to any new information appropriately.
+ </para>
+ </section>
+ <section id="sect-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot-Shim">
+ <title>The Shim</title>
+ <para>
+ The shim package also contains a blacklist of known bad keys or
+binaries that should not be allowed to boot. Microsoft will provide this
+list to Fedora for inclusion. This may create periodic update to the
+shim-signed package that do not change the actual shim binary, but will
+update the blacklist to ensure known bad code cannot be executed.
+ </para>
+ <para>
+ In both methods, shim, grub2, and the kernel will detect that they
+are started in what UEFI describes as "User mode" with Secure Boot enabled,
+and upon detecting this they will validate the next stage with a
+Fedora-specific cryptographic public key before starting it. The validation
+is done via shim for grub2, and grub2 calls back to shim to validate the
+kernel as well. Once the kernel is booted, it will also detect that it is
+in Secure Boot mode, which will cause several things to be true:
<simplelist>
<member>it will validate the boot command line to only allow certain kernel settings</member>
<member>it will check modules at load time for signatures and refuse to load them if they are unsigned or signed with a signature not found in the UEFI key store variables (see note)</member>
<member>it will refuse any operations from userland which cause userland-defined DMA.</member>
</simplelist>
- </para>
- <para>
+ </para>
+ </section>
+ <section id="sect-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot-Restrictions">
+ <title>Restrictions</title>
+ <para>
These restrictions are in place to be fully compliant with Secure Boot. This requires us to prevent any execution of unverified code at the supervisor level. Most users won't notice these restrictions as most of the userspace packages that required such access have been fixed to work without it. However, there are a few services or features that will not work in a Secure Boot enabled machine at this time. They include:
<simplelist>
<member>kexec/kdump</member>
@@ -24,14 +53,29 @@
<member>third party modules that are unsigned, or signed with an unknown key</member>
<member>systemtap kernel probing (and kprobes)</member>
</simplelist>
- </para>
- <para>
- In future iterations of Secure Boot support the above may also be possible, however secure implementations were not feasible in the Fedora 18 timeframe.
- </para>
+ </para>
+ <para>
+ In future iterations of Secure Boot support the above may also be
+possible, however secure implementations were not feasible in the Fedora 18
+timeframe. If you require support of any of these featurs, Secure Boot must
+be disabled.
+ </para>
<note>
<title>Note</title>
<para>Other distributions have chosen to not require signed kernel modules in their Secure Boot implementation. Fedora believes that to fully support Secure Boot this is required. We are working to limit the impacts of this while ensuring that untrusted module code is not allowed to execute.
</para>
</note>
+ <important>
+ <title>Important</title>
+ <para>
+ Currently, the Fedora shim was signed in a way that gives it an
+expiration date of October 2013, prior to the Fedora 18 end-of-life. We are
+not aware of any hardware that honors this expiration date, but it's not
+out of the question. This is the date Microsoft gave the signature, Fedora
+has no control over it. We are investigating this issue and expect to
+resolve it in the future.
+ </para>
+ </important>
+ </section>
</chapter>