potiuk commented on PR #160:
URL: https://github.com/apache/solr-mcp/pull/160#issuecomment-5117127746
Thanks both — pushed as `3084fe5`.
**@epugh** — this is the next set of changes you asked for. Aditya's answers
are now folded into the document body rather than sitting in the review thread,
so the claims read as the project's own position instead of our reading of it.
Concretely:
- All 13 inline `*(inferred)*` provenance tags are now `*(maintainer)*`. No
inferred claims remain.
- The precision points Aditya added are in the body where a triager will
actually hit them — §5a now records that the HTTP transport is stateless and
that `/mcp` is `permitAll()` with auth enforced by
`@PreAuthorize("isAuthenticated()")` on every tool, resource, prompt and
completion handler; §6 records that `collection` can't escape the fixed
`SOLR_URL` host and that there's no server-side bound on `rows`/facets/body
size; §9 records that no `q`/`fq` escaping is performed, citing #122 and #127
as the closed-by-design precedent.
- §11a gained two entries. One is the `permitAll()` reading — that's
precisely the false positive an automated scanner will file, so it's now
pre-empted, with the carve-out that an entry point found *without* the
annotation would be a real finding.
- Admin-tool exposure and read-only-subset proposals route to #66, in both
§9 and the §13 disposition table.
- §14 is rewritten as maintainer answers, attributed and dated.
The `SECURITY.md` disclosure address was already aligned to
`[email protected]` back in `440d5d4`, so that item from your list was
closed.
**@janhoy** — thanks, that's a useful framing and I've recorded it as
`Q-tenancy` in §14, deliberately **not** written into §2/§8/§10. You asked
whether to decide here or take it to the dev list, so it isn't ours to settle —
putting it in as a maintainer position while that's live would misrepresent the
project.
Two observations for when you do pick it up. First, it strengthens §10
(downstream responsibilities) rather than changing any §8 claim: the server
gains no new property, it makes an existing operator assumption explicit and
testable — which is the useful kind of threat-model statement, because it
converts "user Y did destructive thing Z" from an ambiguous report into a
Solr-side misconfiguration by construction. Second, it interacts with #66: if
per-tool roles land server-side, one-instance-per-user becomes a recommendation
rather than the only supported mode, which is a §12 model-changing event.
Happy to draft the §2/§10/§11a wording once you've decided, or to leave it
entirely with the project. Either way it doesn't hold anything up — an
undecided question recorded as undecided is a perfectly good state for a threat
model to be in.
From our side this is ready to merge.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
