Repository navigation
Release v1.3.1 and re-pin keep to v0.11.0 - #534
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configuration
📒 Files selected for processing (12)
Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review. WalkthroughThe app version changes to 1.3.1, and the ChangesRelease metadata
Priority: ➖ Normal Estimated code review effort: 1 (Trivial) | ~8 minutes Change: Other Merge Risk: ⚪ Minimal · up to The release metadata and localized notes are updated, and the build checks the pinned revision. The source behind that revision could not be independently verified, but no concrete mismatch or build failure is established. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. A rabbit reads the release notes by moonlit clover, Comment |
Prepares v1.3.1:
versionCode29 to 30,versionName1.3.0 to 1.3.1, the per-ABI Fastlane changelogs (302, 304) in all five locales, and a re-pin of keep to the v0.11.0 release tag. F-Droid reads changelogs from the source tree at the tagged commit, so they have to land before the tag.This is a security release. v1.3.0 ships a core whose sign-policy gate is evaluated before app expiry, before the standing-permission lookup and before a stored refusal, so an app the user had explicitly denied could still be auto-approved, provided it was opted in to background signing and the policy was Auto or Basic. An expired app could be auto-approved the same way, and an indeterminate permission lookup was bypassed rather than failing closed. keep v0.11.0 evaluates expiry, the lookup and a standing DENY ahead of the policy, and an explicit "ask" now prompts rather than being overridden. The reject reasons are unchanged; what changes is which requests reach them.
Pinned to the tag's commit,
7de93595, not the tag object..github/actions/setup-keepresolves the tag to its commit and then compares that againstkeep.version, so the tag object's own SHA fails the check. keep v0.11.0's NDK, cargo-ndk and Rust pins match this repo's, verified byscripts/check-toolchain-pins.sh.Paired with #533, which is the client half of the same fix. The two are separable only in the sense that they merged separately: #533 makes an expired window require re-approval and stops the sweep erasing a standing refusal, and without it the re-pin would make
deny_expiredreachable for exactly the apps whose refusal the sweep was deleting. Also includes #532, which gives the core-owned store sole ownership of the per-app policy tier.Changelogs
The three user-visible changes, in the order they are likely to be noticed: a remembered refusal now holds while automatic approval is on; a permission set to ask now asks; and an app whose access window has run out must be approved again instead of falling back to the default policy, with its background-signing permission withdrawn. The third is the one most likely to prompt "why is it asking me again", so it is stated plainly rather than implied.
Test plan
scripts/check-release-changelogs.shandscripts/check-toolchain-pins.shpass locally, including the 500-character cap added in Trim v1.2.0 changelogs to 500 characters and check every changelog's length #531.workflow_dispatchrun on main after merge, and the tag-triggered run then compares the published APKs byte for byte.Summary by CodeRabbit
Release
Permission behavior