potiuk opened a new pull request, #3478:
URL: https://github.com/apache/pekko/pull/3478
### Motivation
The Pekko PMC asked the ASF Security team for a draft threat model to
refine, as
preparation for a Claude security scan. Pekko already documents its security
posture
well — `remote-security.md`, `serialization.md` and `remoting.md` between
them state
most of the trust model — but that material is spread across three files and
states it
implicitly, rather than in a form a triager (or a scanning agent) can cite
when
classifying a finding.
Separately, the `AGENTS.md` → `SECURITY.md` chain that a scanning agent
follows to
locate a project's model does not resolve today: there is no `SECURITY.md`
in the repo.
### Modification
- **`THREAT_MODEL.md`** — a v0 draft. Every claim is tagged `(documented)`
with a
citation into Pekko's own docs, or `(inferred)` with a matching open
question in §14.
**40 documented / 0 maintainer / 14 inferred.**
- **`SECURITY.md`** — reporting policy (`[email protected]`; Pekko does
not operate a
separate project security list), a link to the threat model, and the two
assumptions
that catch most reporters.
- **`AGENTS.md`** — a `## Security` section pointing at both.
Nothing the existing docs assert has been dropped or weakened. **§15 is a
back-map**
from each existing statement to the section that now carries it, so you can
diff the two.
### Result
The chain `AGENTS.md` → `SECURITY.md` → `THREAT_MODEL.md` resolves on
`main`, and
triagers get a citable document with a closed set of dispositions (§13).
**§14 holds 13 questions, each stated as a proposed answer** — confirming or
correcting
is enough, no prose needed. The two that most change the document:
- **Q1** — `pekko.remote.artery.transport` ships `tcp`, so a stock cluster
has no peer
authentication. Is that the supported production posture *given the
documented
network-isolation assumption*, so a report of "unauthenticated peer can
associate" is
out of model when it assumes internet exposure — but valid if it shows
harm reachable
**pre-association** from an adjacent-network host?
- **Q4** — are `untrusted-mode` and the remote deployment allow list
**security
boundaries**, or **hardening**? The draft says hardening, on the strength
of the
documented *"untrusted mode does not give full protection against attacks
by itself"*.
One conclusion is worth flagging explicitly because it disposes of a whole
class of
scan findings: the draft reads §7 as having **no Byzantine-peer model**, on
the strength
of *"you'll have to trust all cluster nodes the same in a Pekko cluster
anyway"* and
*"as soon as an actor system can connect to another remotely, it may in
principle send
any possible message to any actor contained within that remote system."* If
that
generalises from remoting to sharding, singleton and `distributed-data`
(Q9), then any
finding whose precondition is "a cluster member misbehaves" is out of model.
**This is a draft and should not be treated as canonical until at least Q1
and Q4 are
answered.** Happy to fold the answers in and push, or hand it over entirely
— the PMC
owns the document.
### Tests
Not run - docs only
### References
None - requested by the Pekko PMC chair on the ASF security scan thread
--
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]
