feat: validate Cron provenance at API boundary - #228
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5a17d7b414
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| && value.provider === "cron" | ||
| && value.assertionKind === "declared" | ||
| && value.providerSlot === "cron" | ||
| && (value.freshness === "fresh" || value.freshness === "stale" || value.freshness === "timed_out"); |
There was a problem hiding this comment.
Bind V4 evidence freshness to the Cron provider state
When a daemon returns internally inconsistent Cron data, this branch accepts the evidence freshness independently of the cron entry in providerStates; the added test at security.test.ts:1299-1307 even changes only the evidence to stale or timed_out while leaving the slot fresh. The real daemon derives the evidence freshness, providerRevision, and collectedAt from that exact slot in bind_cron_evidence, so a malformed daemon response can now publish impossible Cron provenance. Require these evidence fields to agree with the corresponding Cron provider state.
Useful? React with 👍 / 👎.
5a17d7b to
8d069ab
Compare
Summary
Checks