Now they live in tests/component/edify_test.cpp.
Also rename edify/main.cpp to edify/edify_parser.cpp. It becomes a
host-side debugging tool that validates the input edify script. However,
it supports edify builtin functions only and doesn't recognize the ones
defined via updater.
Test: recovery_component_test passes on device.
Change-Id: Ib94a787bf15098a9cc078d256b6a6dc96ff12b2e
A Certificate is a pair of an RSAPublicKey and a particular hash. So v1
and v3 differ in the hash algorithm (SHA-1 vs SHA-256), similarly for
v2 and v4.
In verifier testcases, we used to load v1/v2 keys with an explicit
argument of "sha256" to test the v3/v4 keys. This CL switches to loading
v3/v4 keys directly and lets load_keys() to handle that, which is the
actual flow we use in practice.
Also remove the "fallback to v1 key" in the testcases, which is not the
actual behavior.
Bug: 30415901
Test: Run the verifier_test component test on device.
Change-Id: I3a2baa64826f1b6c4c367a560090df384c4521bb
Add a new command "--security" to boot commands. If this command is
observed as part of BCB, choose a different background text picture
for installing stage in recovery UI. As a result, users will see
"installing security update" instead of "installing system update"
when applying a security update package.
Bug: 27837319
Change-Id: I2e2253a124993ecc24804fa1ee0b918ac96837c5
This changes the verification code in bootable/recovery to use
BoringSSL instead of mincrypt.
Cherry-pick of 452df6d99c, with
merge conflict resolution, extra logging in verifier.cpp, and
an increase in the hash chunk size from 4KiB to 1MiB.
Bug: http://b/28135231
Change-Id: I1ed7efd52223dd6f6a4629cad187cbc383d5aa84
