summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorDaniel Micay <danielmicay@gmail.com>2019-04-27 23:04:01 -0400
committerDaniel Micay <danielmicay@gmail.com>2019-04-27 23:04:01 -0400
commit298faca01ed7eb414db4773c34174f19543988ca (patch)
tree068b3720396720c1b24a7291c933c473db6cb0b8
parentdef06a686ce484d2820c3cd9c4d11f391e1696b1 (diff)
move section on generating release signing keys
This no longer needs to be done before building since the Pixel and Pixel XL are not (currently) supported.
-rw-r--r--static/build.html60
1 files changed, 30 insertions, 30 deletions
diff --git a/static/build.html b/static/build.html
index 3382999e..c56b8ef5 100644
--- a/static/build.html
+++ b/static/build.html
@@ -208,36 +208,6 @@ mv vendor/android-prepare-vendor/DEVICE/BUILD_ID/vendor/google_devices/* vendor/
<p>Note that android-prepare-vendor is non-deterministic unless a timestamp parameter is
passed.</p>
- <h2>Generating release signing keys</h2>
-
- <p>Keys need to be generated for resigning completed builds from the publicly
- available test keys. The keys must then be reused for subsequent builds and cannot be
- changed without flashing the generated factory images again which will perform a
- factory reset. Note that the keys are used for a lot more than simply verifying
- updates and verified boot.</p>
-
- <p>The keys should not be given passwords due to limitations in the upstream scripts.
- If you want to secure them at rest, you should take a different approach where they
- can still be available to the signing scripts as a directory of unencrypted keys. The
- sample certificate subject can be replaced with your own information or simply left
- as-is.</p>
-
- <p>To generate keys for crosshatch (you should use unique keys per device
- variant):</p>
-
- <pre>mkdir -p keys/crosshatch
-cd keys/crosshatch
-../../development/tools/make_key releasekey '/CN=GrapheneOS/'
-../../development/tools/make_key platform '/CN=GrapheneOS/'
-../../development/tools/make_key shared '/CN=GrapheneOS/'
-../../development/tools/make_key media '/CN=GrapheneOS/'
-openssl genrsa -out avb.pem 2048
-../../external/avb/avbtool extract_public_key --key avb.pem --output avb_pkmd.bin
-cd ../..</pre>
-
- <p>The <code>avb_pkmd.bin</code> file isn't needed for generating a signed release but
- rather to set the public key used by the device to enforce verified boot.</p>
-
<h2>Building</h2>
<p>Incremental builds (i.e. starting from the old build) usually work for development
@@ -274,6 +244,36 @@ cd ../..</pre>
lot more sense to test it with proper signing keys rather than the default public test
keys.</p>
+ <h2>Generating release signing keys</h2>
+
+ <p>Keys need to be generated for resigning completed builds from the publicly
+ available test keys. The keys must then be reused for subsequent builds and cannot be
+ changed without flashing the generated factory images again which will perform a
+ factory reset. Note that the keys are used for a lot more than simply verifying
+ updates and verified boot.</p>
+
+ <p>The keys should not be given passwords due to limitations in the upstream scripts.
+ If you want to secure them at rest, you should take a different approach where they
+ can still be available to the signing scripts as a directory of unencrypted keys. The
+ sample certificate subject can be replaced with your own information or simply left
+ as-is.</p>
+
+ <p>To generate keys for crosshatch (you should use unique keys per device
+ variant):</p>
+
+ <pre>mkdir -p keys/crosshatch
+cd keys/crosshatch
+../../development/tools/make_key releasekey '/CN=GrapheneOS/'
+../../development/tools/make_key platform '/CN=GrapheneOS/'
+../../development/tools/make_key shared '/CN=GrapheneOS/'
+../../development/tools/make_key media '/CN=GrapheneOS/'
+openssl genrsa -out avb.pem 2048
+../../external/avb/avbtool extract_public_key --key avb.pem --output avb_pkmd.bin
+cd ../..</pre>
+
+ <p>The <code>avb_pkmd.bin</code> file isn't needed for generating a signed release but
+ rather to set the public key used by the device to enforce verified boot.</p>
+
<h2>Generating signed factory images and full update packages</h2>
<p>Generate a signed release build with the release.sh script:</p>