- No patches were found with incorrect authorship/From: lines
- The older AndroidHardening patch repos are no longer available to verify CID.
- New GrapheneOS patches do not include a CID.
- *Signature_Spoofing.patch CID could not be found.
- Fixed CID of *Harden_Sig_Spoofing.patch to match 14.1
- Fixed CID of *LGE_Fixes.patch to match 14.1
- Fixed CID of *Harden.patch to match 14.1
- Added edit note to *Harden.patch
- Fixed CID of *PREREQ_Handle_All_Modes.patch to match 14.1
- Fixed CID of *More_Preferred_Network_Modes.patch to match 14.1
- Fixed CID of *AES256.patch to match 14.1
- Fixed CID of *0001-OTA_Keys.patch to match 18.1
- Fixed CID of *Camera_Fix.patch to match 15.1
- Fixed CID of *Connectivity.patch to match 14.1
- Fixed CID of *Fix_Calling.patch to match 14.1
- Fixed CID of *Remove_Analytics.patch to match 14.1
- Fixed CID of Unused-*.patch/audio_extn to match original
Signed-off-by: Tad <tad@spotco.us>
PRODUCT_OTA_PUBLIC_KEYS is meant to be set by a vendor tree, something
we don't use.
Override it at the source and set it explicitely as well.
This ensures that the compiled recovery.img and the one generated by
sign_target_files_apks.py includes the real public keys for verification.
11.0 signing is ignored.
This will need to be extensively tested as breakage can mean brick on locked
devices.
Although in failure cases it seems test-keys are accepted.
--
After much testing there appears to be a deeper issue with how keys
are inserted into the recovery and handled
- 15.1+16.0: Replace in-line build signing patch with bash function
- From GrapheneOS/script
- 15.1+16.0: Enable fingerprint failed lockout after 5 attempts
- From GrapheneOS
- Disable patches with restrictive licenses by default
- Update LICENSE
- Fixup the fix for F-Droid building
- 15.1: Fix forceencrypt on mako
- 15.1: Fix crashes when accessing factory reset and development settings menus
on devices without support for factory reset protection or oem unlocking
While some tasks complete slightly faster overall there are too many downsides
- Too large system images
- Weird compiler errors
- Performance regressions on some devices
- General maintenance overhead
Maybe a less aggressive variant can be brought back in the future
