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/
Note that android-prepare-vendor is non-deterministic unless a timestamp parameter is passed.
-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.
- -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.
- -To generate keys for crosshatch (you should use unique keys per device - variant):
- -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 ../..- -
The avb_pkmd.bin
file isn't needed for generating a signed release but
- rather to set the public key used by the device to enforce verified boot.
Incremental builds (i.e. starting from the old build) usually work for development @@ -274,6 +244,36 @@ cd ../.. lot more sense to test it with proper signing keys rather than the default public test keys.
+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.
+ +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.
+ +To generate keys for crosshatch (you should use unique keys per device + variant):
+ +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 ../..+ +
The avb_pkmd.bin
file isn't needed for generating a signed release but
+ rather to set the public key used by the device to enforce verified boot.
Generate a signed release build with the release.sh script: