potiuk commented on PR #2186:
URL: https://github.com/apache/activemq/pull/2186#issuecomment-4882691125
`mattrpav` thanks for jumping in and for the first-pass edits — much
appreciated.
Two equally-good ways to handle this; pick whichever is less friction for
you:
**Option A — just answer inline (easiest).** Drop a comment on this PR with
one line per §14 question: *confirm / correct / strike*. That's genuinely all
we need — I fold the answers into `THREAT_MODEL.md` and push the revision back
to this branch, so the PMC never has to touch the doc mechanics. This is how
most projects have done it (examples below).
**Option B — edit the doc directly** in the branch, if you'd rather own the
wording. The mechanics for that are below.
**On the "leave the references or remove them?" question — leave them, just
flip the tag.** The provenance tags are load-bearing (they tell the scan agent
and future readers which claims the PMC has *ratified* vs. which are still our
guess), so they stay for the life of the doc. What changes per answered
question is three small things:
1. Flip every matching `*(inferred — see §14 Qn)*` tag in the body to
`*(maintainer)*` (or to `*(documented — <cite>)*` if it turns out a project doc
already says it).
2. Fold the substance of your answer into the surrounding prose if it
corrects or sharpens the claim.
3. Retire the §14 question itself once it's fully resolved — that numbered
entry is scaffolding and *does* get removed (or struck). The tag in the body is
what persists.
So: references-in-the-body stay (re-tagged); the §14 question goes away.
**Worked example — moving Q9 (peer broker) from inferred → confirmed.**
The claim today, in §2, reads:
> - **Peer broker (authenticated but adversarial):** the other end of a
network-of-brokers link. Holds a legitimate identity but can behave
arbitrarily. *(inferred — see §14 Q9)*
and §14 Q9 asks whether ActiveMQ provides any cross-link safety guarantee or
whether a malicious peer is wholly the operator's trust decision.
Say the PMC answers: *"No cross-link authorization guarantee — a
compromised/malicious peer is the operator's trust decision."* After folding
that in, the §2 bullet becomes:
> - **Peer broker (authenticated but adversarial):** the other end of a
network-of-brokers link. Holds a legitimate identity but can behave
arbitrarily; the broker provides **no forwarded-message authorization
guarantee** across the link, so a compromised peer is the operator's trust
decision. *(maintainer)*
…and §14 Q9 is deleted. That's the whole transformation — tag flips, the
answer's substance lands in the prose, question retires. A one-line "Q9:
confirmed, no cross-link guarantee" from you produces exactly that edit on my
end.
**A few past models where this played out**, if it helps to see the pattern:
- **apache/creadur-rat#677** — Claudenw asked this exact question ("we
answer questions and push the resulting file?"); the thread walked each item,
and answered ones became `(maintainer)` (e.g. the archive-OOM gap, XXE
hardening, the custom-matcher trust surface).
- **apache/helix#3148** — junkaixue confirmed a batch inline (helix-rest
ships auth-less by default, ZK access is ZK-gated, gateway/agent are
pluggable); all folded in as `(maintainer)` in one push.
- **apache/drill#3052** — cgivre *corrected* an inferred call (the
`contrib/` plugins are in-scope, not out) and added a KNOWN-NON-FINDING for
storage enumeration — a good example of the "correct / strike," not just
"confirm," path.
No rush on any of it — one line per question whenever you have a moment is
plenty. Happy to fold as they come in rather than waiting for all ten.
--
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]
For further information, visit: https://activemq.apache.org/contact
