Django is exploring ways to handle security disclosures made publicly in issues/PRs instead of following our documented process. Other Python projects, how do you handle such cases? Share your insights! Also, if you're on GitHub, feel free to upvote & join the discussion: https://github.com/orgs/community/discussions/154262 #Python #Django #Security
@nessita As much as I love GitHub Security Advisories, I do think it was a big mistake to make them some strange second-thing instead of simply adding private issues and pull requests with optional vulnerability metadata.
The API isn't complete for GHSA, it likely would be much better if the whole feature branched out from existing models...
For us we'd likely open a GHSA and delete the public issue if it was sensitive, otherwise we'd leave the issue open and handle it publicly.
@sethmlarson Thank you! This helps. What would you do if there is also a PR with a proposed fix, which discloses a security vulnerability? (Asking since PRs can't be deleted nor hidden AFAIK.)
@nessita CPython publishes advisories as soon as a patch lands in main, before releases go out or that patch is backported. The CVE record gets updated automatically as backports are merged and releases are made. Depending on how long we think a review will take we might try to land it and get an advisory out instead of maintaining secrecy.
@nessita It's also possible to release an advisory with "mitigation" only, without a patch. This gives you more time to work on a real fix while not giving adversaries an information advantage.
It's all context dependent! Happy to help in specific instances.