[kwsantiago]

A signed policy stayed enforceable for a year, which is how far back a rollback could reach. Restoring an older copy of the policy record puts older, more permissive rules back in force, and at a 365 day window rules retired eleven months ago still loaded as active. This shortens the window to thirty days, so a warden renews monthly and a rollback reaches back at most that far.

Why the window rather than a stored floor. The obvious fix is a high-water mark kept in its own record, refusing any bundle below it. It does not hold here. The policy record lives in app-private storage encrypted under a key the app can use without the operator present, so the access needed to restore an older record is also enough to rewrite a floor sitting beside it. A floor also has to be bounded in the forward direction, for the reason monotonic_timestamp in audit.rs already documents: one entry planted far in the future would refuse every legitimate policy after it, and an escape hatch for that either voids the floor or bricks the device. The validity window needs no new record, no protection for that record and no escape hatch, and the machinery it relies on is already built: an expired bundle faults and every rule refuses, while the bundle stays readable so a replacement installs over it rather than requiring the record be deleted first.

What this costs. A device left idle past thirty days comes back with an expired policy, and every rule refuses until a warden signs a new bundle. For an unattended co-signer that is an outage rather than a prompt, which is the deliberate trade: refusing is the safe direction, and recovery is a renewal rather than a reinstall.

What it does not do. Bounding is not preventing. Rollback inside the window still works, and closing that needs a witness the device cannot roll back on its own, meaning a warden-issued epoch checked at import. That is connectivity-dependent and tracked separately rather than folded in here.

The test pins the window in absolute days rather than against the constant. Every other date in these tests is expressed in terms of MAX_POLICY_AGE_SECS, so all of them pass at any window; this one fails if the value changes, which is what makes a future change to it deliberate.

[coderabbitai]

Warning

Review limit reached

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Next included review available in 38 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: a8cd18d5-5dc3-4169-a021-87b14022a8b3

📥 Commits

Reviewing files that changed from the base of the PR and between a452f5b and 256dff1.

📒 Files selected for processing: 1

• keep-mobile/src/policy.rs

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}