[uefi-secure-boot-guide] master: Merge branch 'master' of git://git.fedorahosted.org/git/docs/uefi-secure-boot-guide into bressers (30a75a5)

[sparks at fedoraproject.org]

Repository : http://git.fedorahosted.org/git/?p=docs/uefi-secure-boot-guide.git

On branch  : master

>---------------------------------------------------------------

commit 30a75a5e95224ae7c2667b9b5afde317f98d5483
Merge: 11756fa 49b6425
Author: Josh Bressers <josh at bress.net>
Date:   Thu Jan 31 12:36:59 2013 -0600

    Merge branch 'master' of git://git.fedorahosted.org/git/docs/uefi-secure-boot-guide into bressers
    
    Conflicts:
    	en-US/Implementation_of_Secure_Boot.xml
    	en-US/What_is_Secure_Boot.xml



>---------------------------------------------------------------

 en-US/Implementation_of_Secure_Boot.xml |   12 ++++++------
 en-US/UEFI_Secure_Boot_Guide.ent        |    1 +
 en-US/What_is_Secure_Boot.xml           |   10 +++++-----
 3 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/en-US/Implementation_of_Secure_Boot.xml b/en-US/Implementation_of_Secure_Boot.xml
index 757f7ff..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.
-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
+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.
+&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:
diff --git a/en-US/UEFI_Secure_Boot_Guide.ent b/en-US/UEFI_Secure_Boot_Guide.ent
index e746308..b1f8562 100644
--- a/en-US/UEFI_Secure_Boot_Guide.ent
+++ b/en-US/UEFI_Secure_Boot_Guide.ent
@@ -1,4 +1,5 @@
 <!ENTITY PRODUCT "Fedora">
+<!ENTITY PROJECT "Fedora Project">
 <!ENTITY BOOKID "UEFI_Secure_Boot_Guide">
 <!ENTITY YEAR "2012-2013">
 <!ENTITY HOLDER "Fedora Project Contributors">
diff --git a/en-US/What_is_Secure_Boot.xml b/en-US/What_is_Secure_Boot.xml
index 49c7b7f..1cb0b84 100644
--- a/en-US/What_is_Secure_Boot.xml
+++ b/en-US/What_is_Secure_Boot.xml
@@ -12,7 +12,7 @@
 	Earlier versions of &PRODUCT; booted on such hardware will refuse to boot until the user disables Secure Boot in the firmware.  While disabling Secure Boot is a viable option that some users may wish to choose, it is not an optimal solution.
 	</para>
 	<para>
-	To facilitate out of the box functionality on new hardware, the maintainers of the grub2, kernel and associated packages have implemented Secure Boot support in &PRODUCT;.  On UEFI machines, &PRODUCT; uses a small bootloader called "shim" that has been signed by the Microsoft signing service (via Verisign).  This allows UEFI to load shim on Windows 8 client ready machines and continue the boot process for Linux.  Shim in turn boots grub2, which is signed by a &PRODUCT; key.  Grub2 then boots a similarly signed Linux kernel provided by Fedora which loads the rest of the OS as per the usual boot process.  The machine remains in Secure Boot mode.
+	To facilitate out of the box functionality on new hardware, the maintainers of the grub2, kernel and associated packages have implemented Secure Boot support in &PRODUCT;.  On UEFI machines, &PRODUCT; uses a small bootloader called "shim" that has been signed by the Microsoft signing service (via Verisign).  This allows UEFI to load shim on Windows 8 client ready machines and continue the boot process for Linux.  Shim in turn boots grub2, which is signed by a &PRODUCT; key.  Grub2 then boots a similarly signed Linux kernel provided by &PRODUCT; which loads the rest of the OS as per the usual boot process.  The machine remains in Secure Boot mode.
 	</para>
 	<section id="sect-UEFI_Secure_Boot_Guide-What_is_Secure_Boot-Protect_you_from">
 		<title>What does Secure Boot protect you from?</title>
@@ -25,8 +25,8 @@ extend this chain of trust down into user binaries, but that moves us
 outside of the concept of Secure Boot and into another topic.
 		</para>
 		<para>
-		Fedora has expanded the chain of trust into the Kernel.
-Verification happens as far as only loadin signed kernel modules, but it
+		&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
 initrd cannot currently be signed, it cannot be verified.
@@ -36,8 +36,8 @@ initrd cannot currently be signed, it cannot be verified.
                 <title>What does Secure Boot not protect you from?</title>
                 <para>
 			Secure Boot will not protect your PC from malware or attackers.
-Secure Boot itslef is simply to protect the boot phase of a system. In
-Fedora if you use Secure Boot, what modules the kernel loads can be
+Secure Boot itself is simply to protect the boot phase of a system. In
+&PRODUCT; if you use Secure Boot, what modules the kernel loads can be
 restricted, but user space malware cannot. This of course doesn't mean
 Secure Boot isn't useful, just that it currently only serves a single
 purpose, which is protecting the boot loader.