is there any reason to use custom release scripts like github.com/AndroidHardeni over official build tools like "m dist" for recent devices like blueline/crosshatch ?
Conversation
Replying to
It doesn't do anything close to the same thing. The release.sh script has nothing to do with building. It directly uses the official tools for generating signed releases to generate a release. Most of what the `make dist` target does is a complete waste of time.
1
The subset of `make dist` required for making a release is `make target-files-package`. It's a waste of time to generate a test key signed update package. The otatools.zip is only useful if you want to package up and move the tools used to generate a release (why?).
1
The `make dist` target does NOT generate a signed, production release. It does a lot of useless stuff like packaging up the signing tools from the source tree and output and generating a strictly GPL compliance related userspace source tarball without anything non-mandatory.
1
The release.sh script is a thin wrapper around official tools for generating releases. It takes the test key signed target-files-package built by make and turns it into a signed release by replacing all apk signatures, verity trees, image signatures, OTA keys, etc.
1
For development, `make -j36` works well. For releases, `make -j36 target-files-package brillo_upload_payload` is the target. The target-files-package is the input format used by the post-build tools for generating releases. Generating signed releases isn't part of building.
1
Generating a signed target-files-package from the freshly built target-files-package is a post-build step. The signed target-files-package gets transformed into an image zip and a signed update package. The image zip and firmware are transformed into a factory images release.
1
The signed target-files-package need to be kept in archive for generating delta update packages. That's the same to generating a regular update, but with a source target-files-package passed as an extra argument. Updates are block-based so installs remain bit-for-bit identical.
1
The public release script is minimal and uses a keys/ directory in the source tree. I have additional local changes and scripting for using an HSM for the signing keys. I'll likely eventually move to using a Trezor Model T instead of a traditional HSM, for new releases at least.
2
Replying to
Using a Yubikey, Trezor or other PKCS#11/x509 capable device is my first goal, but my end game would be to use the new m-of-n threshold signing OpenSC and others support. That combined with easily reproducible builds and we avoid SPOF :)
1
Replying to
It's mandatory to have a single RSA or ECDSA signing key for verified boot because it's what devices implement. App signatures are part of the OS API and don't implement an m-of-n signing threshold. Signatures for update packages and payloads are the only part you could change.
It's usually a wise idea to avoid making changes that cannot be easily dropped in the next release, since otherwise you lock them in as mandatory features to preserve forever. It can end up killing the project if it becomes too difficult to quickly port to new major releases.
3
Replying to
Agreed there. This is why I don't want to release binaries until I am confident I have a solid signing/verification story.
Would love a signing scheme along the lines of Shoup's "Practical Threshold Signatures" iacr.org/archive/eurocr or that used in ESKM research.vmware.com/publications/d
Replying to
I am not talking about device-enforced multisig. I am talking about Boneh style Threshold Signing, where you can have multiple private keys that allow creation of a signature that will validate against one public key. The device should not know or care multiple keys were used.
1