Docs: link security vulnerability reports from CONTRIBUTING.md
Assessment
- Difficulty
- 1/5
- Estimated time
- Under an hour
- Newbie friendliness
- 85/100
- Issue type
- Documentation
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- python
- Domain
- documentation, security
Research direction
Read .github/CONTRIBUTING.md near the bug-report guidance and check the private reporting instructions in .github/SECURITY.md. Add a brief cross-reference directing vulnerability reports to the security policy. Done when readers of the contributing guide are clearly told not to report vulnerabilities in public issues and can find the private process.
Written by the indexing model from the issue text.
Description
Summary
The contributing guide explains how to file a good bug report, including providing a complete traceback and a small, reproducible example. It does not appear to direct readers reporting a security vulnerability to the private disclosure process described in the security policy.
Someone reading the contributing guide directly could mistake the public bug-report process for the right place to share vulnerability details.
Relevant guidance
.github/CONTRIBUTING.mddescribes the information expected in a good bug report..github/SECURITY.mdasks reporters to use a private draft Security Advisory and says, “Please do not disclose this to anyone else.”
GitHub already surfaces the security policy when creating an issue, so this may not affect users who start from the issue form. A brief cross-reference in the contributing guide could also help people who arrive there directly.
Suggested change
Add a short note near the bug-report guidance, for example:
Found a security vulnerability? Please do not report it in a public issue. Follow our security policy to report it privately.
Would a note like this be useful?
- Dominant language
- Python
- Stars
- 54.6k
- Forks
- 12.1k
- Avg merge
- 18m
- Merged PRs (30d)
- 1
Getting set up
- No Dockerfile or Docker Compose file
- No 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 psf/requests
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
Difficulty 1/5 Under an hour Newbie friendliness 72/100
-
TestTimeout abandons three delay/10 requests and later tests wait out the serverMay be free again @hananbahi527 claimed this 15 days ago, and no pull request is open. Open
Difficulty 1/5 Under an hour Newbie friendliness 90/100
-
Incorrect type annotation for iter_linesMay be free again @nightcityblade claimed this 35 days ago, and no pull request is open. Open
Difficulty 1/5 Under an hour Newbie friendliness 84/100
Similar issues
-
Support .aac audio uploadsPossibly taken @julien731 claimed this today. Openfeature
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
nimblehq/audio-transcriber#153 ·
-
help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
antonyrag/ragleap-core#1062 ·
-
needs-triage
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
gke-labs/kube-agents#4321 ·
Maintainers usually reply within 1 day
-
enhancement help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Git-Hospital/githealthcheck#61 ·
Maintainers usually reply within 1 day
-
changelog investigate
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
ramnes/notion-sdk-py#433 ·