Where did "audit finding #13" come from, and what happened to findings 1-12 and 14+? #1

New issue

Open

opened 2026-08-26 04:55:42 +00:00 by jlxq0 · 0 comments

jlxq0 commented

2026-08-26 04:55:42 +00:00

Owner

src/session.rs cites a numbered security audit that has no record anywhere I
can find, in a repository that has never had an issue.

Three citations, all in one file:

src/session.rs:1 — "Session-management hardening (audit finding #13)."
src/session.rs:55 — "This is Mitigation A from audit finding #13."
src/session.rs:106 — "(Mitigation B, audit finding #13)."

What is missing

There is no issue #13. jlxq0/hevy-mcp has zero issues and zero pull requests,
in any state, as of 2026-08-26 — open_issues_count is 0 and
GET /issues?state=all&type=issues returns an empty list. The repository's
five commits all landed on 2026-08-17 and none of their messages mention an
audit. A fleet-wide issue search for hevy returns only oddie-apps/platform
deployment issues and one oddie-apps/edge-config TLS issue, none of which is
a security review of this code.

So the citation resolves to nothing, and findings 1 through 12 and 14 onward
have no record at all. Either that audit lives somewhere it should not, or
twelve findings were lost.

Why this is worth an issue rather than a docstring edit

The two mitigations themselves are real and are in the code: SESSION_KEEP_ALIVE
at src/session.rs:51 and the MAX_SESSIONS cap enforced in
CappedSessionManager::create_session. This issue is not about whether #13 was
fixed — it visibly was. It is about the other findings, whose status nobody can
state.

An unanswerable citation in a security-relevant file is worse than no citation,
because it reads as evidence that a review happened and was tracked. It was
tracked somewhere with no state, which is the thing our own rule says not to do:
a defect written into prose has no state, so nothing happens to it.

What would close this

One of:

The audit surfaces, its findings become issues here, and the three docstrings
cite issue numbers in this repository.
The audit is confirmed lost, the docstrings are rewritten to describe the
defence without the dangling number, and a fresh review is scheduled to
re-derive what findings 1-12 and 14+ were.

Not acceptable: silently deleting "#13" from the three comments. That removes
the evidence that the other findings existed.

Asked of whoever ran it

Where does the numbering come from, and what were the other findings?

`src/session.rs` cites a numbered security audit that has no record anywhere I can find, in a repository that has never had an issue. Three citations, all in one file: - `src/session.rs:1` — "Session-management hardening (audit finding #13)." - `src/session.rs:55` — "This is Mitigation A from audit finding #13." - `src/session.rs:106` — "(Mitigation B, audit finding #13)." ## What is missing There is no issue #13. `jlxq0/hevy-mcp` has zero issues and zero pull requests, in any state, as of 2026-08-26 — `open_issues_count` is 0 and `GET /issues?state=all&type=issues` returns an empty list. The repository's five commits all landed on 2026-08-17 and none of their messages mention an audit. A fleet-wide issue search for `hevy` returns only `oddie-apps/platform` deployment issues and one `oddie-apps/edge-config` TLS issue, none of which is a security review of this code. So the citation resolves to nothing, and findings 1 through 12 and 14 onward have no record at all. Either that audit lives somewhere it should not, or twelve findings were lost. ## Why this is worth an issue rather than a docstring edit The two mitigations themselves are real and are in the code: `SESSION_KEEP_ALIVE` at `src/session.rs:51` and the `MAX_SESSIONS` cap enforced in `CappedSessionManager::create_session`. This issue is not about whether #13 was fixed — it visibly was. It is about the other findings, whose status nobody can state. An unanswerable citation in a security-relevant file is worse than no citation, because it reads as evidence that a review happened and was tracked. It was tracked somewhere with no state, which is the thing our own rule says not to do: a defect written into prose has no state, so nothing happens to it. ## What would close this One of: 1. The audit surfaces, its findings become issues here, and the three docstrings cite issue numbers in this repository. 2. The audit is confirmed lost, the docstrings are rewritten to describe the defence without the dangling number, and a fresh review is scheduled to re-derive what findings 1-12 and 14+ were. Not acceptable: silently deleting "#13" from the three comments. That removes the evidence that the other findings existed. ## Asked of whoever ran it Where does the numbering come from, and what were the other findings?

No labels

waiting-on-julian

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

jlxq0/hevy-mcp#1

No description provided.

Rows
Columns