PawletOS-Build/docs/security-patch-process.md

Security patch process

There is no automatic mechanism that applies AOSP security bulletin patches to PawletOS. This is a manual, recurring task. This doc is the checklist; run scripts/check_security_patch.py to find out whether it's time to do it.

Why manual

ro.build.version.security_patch (what Settings shows, what attestation checks read) is baked into build.prop at build time from PLATFORM_SECURITY_PATCH, which PawletOS sets via PAWLET_SECURITY_PATCH in vendor/pawlet/config/version.mk. Nothing updates that date except a human deciding a bulletin's patches have actually been backported. Setting the date without doing the backport work is worse than leaving it stale — it's a false claim of patch level to anything that checks it.

PawletOS also doesn't build against plain upstream AOSP for most components — raspberry-vanilla's forks (kernel, build/make, build/soong, etc.) diverge from stock AOSP hashes, so most bulletin patches don't cherry-pick cleanly. Expect manual backport, not git cherry-pick, for anything touching a raspberry-vanilla-forked repo.

Checklist

1. Run python3 PawletOS-Build/scripts/check_security_patch.py. If it says up to date, stop here.
2. Open the bulletin URL it prints (source.android.com/docs/security/bulletin/YYYY-MM-DD). Read the component list — Framework, Media Framework, System, Kernel, vendor-specific (Qualcomm/MediaTek — not relevant to rpi4/5, skip those sections).
3. For each relevant CVE, find the linked AOSP Gerrit patch(es).
4. For each patch, identify which PawletOS-tracked repo it targets (android_local_manifest/common/pawletos.xml and android_local_manifest/rpi/vendor/brcm_rpi.xml list every tracked project) and whether that repo is:
   • Untouched stock AOSP (still synced under its original name, no <remove-project>/fork in the manifest) — cherry-pick should apply cleanly against the matching tag.
   • A raspberry-vanilla or PawletOS fork — diff the patch against the fork's current state first (same technique as the update_engine/TWRP comparisons: shallow-clone both, diff -rq or a throwaway 3-way git merge, see how much actually conflicts) before hand-applying.
5. Apply each patch (or its manual equivalent) to the relevant repo, build, confirm it doesn't break rpi4/rpi5.
6. Bump PAWLET_SECURITY_PATCH in vendor/pawlet/config/version.mk to the bulletin's date.
7. Bump BOARD_AVB_ROLLBACK_INDEX in both pawlet_rpi4/BoardConfig.mk and pawlet_rpi5/BoardConfig.mk — this is what actually blocks downgrade to a build missing the fix; the date bump alone is just a label.
8. Ship as an OTA per the normal release flow.
9. Commit the version.mk/BoardConfig changes with the bulletin date in the message so git log on those files becomes a patch-history audit trail.

Cadence

Bulletins publish monthly (usually 1st, sometimes a mid-month supplemental on the 5th). Run the checker script periodically — cron it, or just run it before cutting any release build.