Use GitHub's private vulnerability reporting: open the repository's Security tab and click "Report a vulnerability". The report stays private, and the advisory and CVE, if one is warranted, come out of the same thread.
If you cannot use GitHub, email camilo.aguilar@gmail.com with the same details you would put in the report.
Do not open a public issue for a vulnerability.
One maintainer runs this project. You get an acknowledgment within 7 days and an assessment — confirmed, not a vulnerability, or needs more information — within 30. I promise communication, not a fix date; the fix date comes out of the assessment.
In scope: the library as shipped — the client and server roles over each
transport, the QUIC packet protection, the crypto primitives, and the
reference DRBG in drbg.[ch].
Out of scope, so triage stays fast:
- Physical side channels: power analysis, electromagnetic leakage, fault injection.
- Attacks that require a malicious
ch_cfg, malicious I/O callbacks, or a compromised platform. The caller is trusted; the peer and the network are not. - Denial of service against the device that runs the caller's code. The caller owns its own event loop and timeouts.
docs/verification.md and docs/decisions.md state the threat model in detail: what is proved, at what bounds, and what is only tested.
There are no releases yet, so fixes land on main. Once there are,
the latest release only: one maintainer does not promise backports.
Coordinated disclosure with a 90-day default, negotiable in either direction — shorter when the fix is easy, longer when a deployment needs it. Reporters get credited in the advisory unless they decline.