Repository navigation
Document latest-stable security support and private reporting #88
Description
Delivery target and current plan
2.x-compatible documentation/packaging — implemented in PR #116, awaiting owner review. The policy accepts reports from any version, concentrates security fixes on the latest stable release and promises no response SLA. Private vulnerability reporting is enabled. SECURITY.md, README/consumer-skill navigation and Composer-archive inclusion are covered by the PR; no runtime API or repository setting changes. Local checks and independent review passed; native CI must be assessed at the current PR head. If release migration #113 lands first, convert the pending patch note before this PR is merged.
Prior investigation, scope and evidence
Problem and current evidence
At published v2.5.0, 83c887a145169b66548de2d2ce875055328c5aa1, there is no SECURITY.md in the root, .github or docs. A read of GET /repos/coisa/error-handler/private-vulnerability-reporting during this update returns enabled: true. Verify the effective security-policy page again when implementing the selected policy.
The private channel already exists; the missing piece is an explicit owner support commitment and discoverable guidance. This is not a newly found vulnerability. Published 2.x, declared PHP compatibility and an unreleased 3.x draft do not establish support windows by themselves.
Scope and decisions needed
The owner chooses which released versions receive security fixes and whether any response/disclosure expectations can be promised. Do not invent an SLA, support duration, email address or unsupported-upstream-PHP commitment.
Add concise English SECURITY.md linking to the existing confidential reporting route; direct ordinary bugs/features to issues. Decide whether the policy should ship in Composer archives and adjust the existing allowlist/check deliberately if so. No repository settings, new transport or runtime API change is needed.
Acceptance
- Record the owner's supported-release policy and distinguish released 2.x from unreleased major work.
- Verify the private route immediately before documenting it, without changing settings.
- Add the policy and a short appropriate entrypoint link; update affected documentation/skill reporting guidance only where the procedure changes.
- Ask for affected version/runtime, impact/preconditions and a minimal synthetic reproduction, not production secrets or customer data.
- Validate links and intended archive inclusion; verify the effective GitHub policy after an owner-approved merge. Use relevant documentation/packaging checks, not unit tests that merely assert policy prose.
- Add a pending patch Changeset under repository policy. No runtime PHPDoc, executable recipe or API migration change is implied.
This work is independent of 3.0 scope 26. Support commitments, merge, release and Pages publication remain owner decisions.
Activity
[-]Document supported releases and the existing private security-reporting channel[/-][+]Document latest-stable security support and private reporting[/+]