diff options
| author | Daniel Micay <danielmicay@gmail.com> | 2019-04-27 23:04:01 -0400 |
|---|---|---|
| committer | Daniel Micay <danielmicay@gmail.com> | 2019-04-27 23:04:01 -0400 |
| commit | 298faca01ed7eb414db4773c34174f19543988ca (patch) | |
| tree | 068b3720396720c1b24a7291c933c473db6cb0b8 | |
| parent | def06a686ce484d2820c3cd9c4d11f391e1696b1 (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.html | 60 |
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> |
