[uefi-secure-boot-guide] master: Replaced 'Fedora' with entity (49b6425)

[sparks at fedoraproject.org]

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

On branch  : master

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

commit 49b6425177f62dba877ccb5e5dd3f2c35fe0b529
Author: Eric Christensen <sparks at 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: