Called out in the testing/release audit as a biggest gap — small in scope, but the discipline matters.
Summary
The project has no SECURITY.md and no documented private vulnerability disclosure path. Anyone who finds a bug with security implications has no signposted alternative to filing it as a public GitHub issue.
Why this matters specifically for ussher
This binary becomes part of sshd's authentication path on every adopting host. Any vulnerability here is, by definition, a security-relevant finding — auth bypass, key injection, privilege escalation, log injection, etc. Forcing finders to either (a) file publicly and tip off attackers before adopters can update, or (b) guess at maintainer email is bad form for a security-sensitive tool. GitHub provides built-in private vulnerability reporting; there's no reason not to enable it.
Approach
Two complementary pieces:
1. Enable GitHub's private vulnerability reporting in the repo's Security settings (https://github.com/dolph/ussher/settings/security_analysis → "Private vulnerability reporting" → Enable). One-click; no code change.
2. Add /home/user/ussher/SECURITY.md with the disclosure path. Suggested skeleton:
# Security Policy
## Reporting a Vulnerability
`ussher` runs in the SSH authentication path on every adopting host, so
security-relevant findings are taken seriously. Please report them privately:
- Preferred: GitHub's private vulnerability reporting at
https://github.com/dolph/ussher/security/advisories/new
- Alternatively: <maintainer-email-or-keybase-or-whatever>
Please do not file public issues for vulnerabilities. We will acknowledge
receipt within <some realistic SLA, e.g. 7 days> and aim to provide a fix
or a mitigating workaround within <e.g. 30 days> for confirmed issues.
## Supported Versions
Security fixes are applied to the latest tagged release. <Or: list a
support window if there is one.>
GitHub picks up SECURITY.md automatically and surfaces it on the repo's "Security" tab and as a "Report a vulnerability" link in the issue-creation flow.
Acceptance criteria
Files
- new
/home/user/ussher/SECURITY.md
Summary
The project has no
SECURITY.mdand no documented private vulnerability disclosure path. Anyone who finds a bug with security implications has no signposted alternative to filing it as a public GitHub issue.Why this matters specifically for
ussherThis binary becomes part of
sshd's authentication path on every adopting host. Any vulnerability here is, by definition, a security-relevant finding — auth bypass, key injection, privilege escalation, log injection, etc. Forcing finders to either (a) file publicly and tip off attackers before adopters can update, or (b) guess at maintainer email is bad form for a security-sensitive tool. GitHub provides built-in private vulnerability reporting; there's no reason not to enable it.Approach
Two complementary pieces:
1. Enable GitHub's private vulnerability reporting in the repo's Security settings (https://github.com/dolph/ussher/settings/security_analysis → "Private vulnerability reporting" → Enable). One-click; no code change.
2. Add
/home/user/ussher/SECURITY.mdwith the disclosure path. Suggested skeleton:GitHub picks up
SECURITY.mdautomatically and surfaces it on the repo's "Security" tab and as a "Report a vulnerability" link in the issue-creation flow.Acceptance criteria
SECURITY.mdexists at the repo root with a documented private disclosure path.Files
/home/user/ussher/SECURITY.md