Offer a working private security report path and safer public log guidance
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 62/100
- Issue type
- Feature
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- github, shell
- Domain
- content, documentation, security
Research direction
Start by reading SECURITY.md, .github/ISSUE_TEMPLATE/bug_report.yml, bin/hermeskey-doctor, and docs/TROUBLESHOOTING.md to trace the current reporting and log guidance. Check the repository’s private vulnerability reporting route and verify that a non-maintainer can find a working private channel. Update the public guidance to require reviewing and redacting logs before sharing, and consider the optional diagnostic bundle requirements only if that feature exists.
Written by the indexing model from the issue text.
Description
Support privacy gap
SECURITY.md correctly says not to open public issues for security-sensitive findings, but GitHub's private vulnerability reporting is currently disabled for this public repository (checked via repository API), and no alternative private contact is specified. Separately, .github/ISSUE_TEMPLATE/bug_report.yml asks for log excerpts without a redaction warning, and bin/hermeskey-doctor / docs/TROUBLESHOOTING.md suggest including diagnostic output and journals in public reports. This can cause customers to post private paths, installed app/device names or third-party journal messages publicly.
Acceptance
- Enable GitHub private vulnerability reporting (or publish a working private maintainer contact) and verify a non-maintainer can find the route. Keep exploitable details out of public issues.
- Change the public bug template, Doctor footer and troubleshooting guidance to say review and redact logs before sharing; never include audio, dictated text, window titles, personal file paths, tokens, or full config contents. Offer a private channel when redaction is uncertain.
- If a future diagnostic bundle exists, generate an allowlisted, bounded, local-only report, require explicit review before user-initiated sharing, and do not auto-upload.
This issue is about safe support workflows, not a request to publish private vulnerability reproductions.
- Dominant language
- Shell
- Stars
- 0
- Forks
- 0
- Avg merge
- 27m
- Merged PRs (30d)
- 21
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from graygarbage/HermesKey
-
privacy ux
Difficulty 4/5 3-5 days Newbie friendliness 48/100
graygarbage/HermesKey#67 ·
Maintainers usually reply within 1 day
-
packaging privacy
Difficulty 5/5 Over a week Newbie friendliness 35/100
graygarbage/HermesKey#66 ·
Maintainers usually reply within 1 day
-
enhancement privacy
Difficulty 5/5 Over a week Newbie friendliness 35/100
graygarbage/HermesKey#65 · 1 comment ·
Maintainers usually reply within 1 day
-
bug privacy
Difficulty 4/5 3-5 days Newbie friendliness 42/100
graygarbage/HermesKey#63 · 1 comment ·
Maintainers usually reply within 1 day
-
github_actions gui
Difficulty 3/5 1-2 days Newbie friendliness 68/100
graygarbage/HermesKey#58 ·
Maintainers usually reply within 1 day
All issues in graygarbage/HermesKey
Similar issues
-
Add PhotocraftOpenenhancement
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 78/100
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
-
needs-triage
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
gke-labs/kube-agents#3394 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day