Conversation
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
There was a problem hiding this comment.
💡 Codex Security Review
Here are some automated security review suggestions for this pull request.
Reviewed commit: ef7891f7eb
Only the user who started this review can view the report in Codex.
ℹ️ About Codex security reviews in GitHub
This is an experimental Codex feature. Security reviews are triggered when:
- You comment "@codex security review"
- A regular code review gets triggered (for example, "@codex review" or when a PR is opened), and you’re opted in so security review runs alongside code review
Once complete, Codex will leave suggestions, or a comment if no findings are found.
| val occurredAt = data.entries.asSequence() | ||
| .filter { it.occurredAt != 0u } | ||
| .map { Instant.ofEpochSecond(it.occurredAt.toLong()) } | ||
| .toSet() |
There was a problem hiding this comment.
Security: Bound timestamps before rebuilding weekly history
While capture is active for a supported package and an on-path peer can alter its plaintext GF2 frames, bound the timestamps passed to recordChangedWeeks. Lines 50-53 collect every nonzero entry before the existing validation/250-observation cap. One valid entry plus 7,101 rejected timestamp-only entries fits in a single 56,371-byte type-21935 payload and forces 7,102 weekly report builds and DB transactions on the sole parser worker. Repeating with a fresh valid action sustains capture starvation. Derive weeks only from accepted inserted observations and cap periods per payload.
Useful? React with 👍 / 👎.
Summary
Verification
:app:testDebugUnitTest— 212 passed:protocol:testDebugUnitTest— 40 passed:app:connectedDebugAndroidTest— 40/40 passed on SM-N976NDABC99E47E2020234C7601B3F513ADAFD50B177A63F8BD37372C2EC6F1B4C0D3Release timing
This PR is intentionally left unmerged. Squash merge, tag, and v2.3.2 release are deferred until the requested post-midnight release step.