123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107 |
- _ _ ____ _
- ___| | | | _ \| |
- / __| | | | |_) | |
- | (__| |_| | _ <| |___
- \___|\___/|_| \_\_____|
- curl security for developers
- ============================
- This document is intended to provide guidance to curl developers on how
- security vulnerabilities should be handled.
- Publishing Information
- ----------------------
- All known and public curl or libcurl related vulnerabilities are listed on
- [the curl web site security page](http://curl.haxx.se/docs/security.html).
- Security vulnerabilities should not be entered in the project's public bug
- tracker unless the necessary configuration is in place to limit access to the
- issue to only the reporter and the project's security team.
- Vulnerability Handling
- ----------------------
- The typical process for handling a new security vulnerability is as follows.
- No information should be made public about a vulnerability until it is
- formally announced at the end of this process. That means, for example that a
- bug tracker entry must NOT be created to track the issue since that will make
- the issue public and it should not be discussed on any of the project's public
- mailing lists. Also messages associated with any commits should not make
- any reference to the security nature of the commit if done prior to the public
- announcement.
- - The person discovering the issue, the reporter, reports the vulnerability
- privately to `curl-security@haxx.se`. That's an email alias that reaches a
- handful of selected and trusted people.
- - Messages that do not relate to the reporting or managing of an undisclosed
- security vulnerability in curl or libcurl are ignored and no further action
- is required.
- - A person in the security team sends an e-mail to the original reporter to
- acknowledge the report.
- - The security team investigates the report and either rejects it or accepts
- it.
- - If the report is rejected, the team writes to the reporter to explain why.
- - If the report is accepted, the team writes to the reporter to let him/her
- know it is accepted and that they are working on a fix.
- - The security team discusses the problem, works out a fix, considers the
- impact of the problem and suggests a release schedule. This discussion
- should involve the reporter as much as possible.
- - The release of the information should be "as soon as possible" and is most
- often synced with an upcoming release that contains the fix. If the
- reporter, or anyone else, thinks the next planned release is too far away
- then a separate earlier release for security reasons should be considered.
- - Write a security advisory draft about the problem that explains what the
- problem is, its impact, which versions it affects, solutions or
- workarounds, when the release is out and make sure to credit all
- contributors properly.
- - Request a CVE number from distros@openwall[1] when also informing and
- preparing them for the upcoming public security vulnerability announcement -
- attach the advisory draft for information. Note that 'distros' won't accept
- an embargo longer than 19 days.
- - Update the "security advisory" with the CVE number.
- - The security team commits the fix in a private branch. The commit message
- should ideally contain the CVE number. This fix is usually also distributed
- to the 'distros' mailing list to allow them to use the fix prior to the
- public announcement.
- - At the day of the next release, the private branch is merged into the master
- branch and pushed. Once pushed, the information is accessible to the public
- and the actual release should follow suit immediately afterwards.
- - The project team creates a release that includes the fix.
- - The project team announces the release and the vulnerability to the world in
- the same manner we always announce releases. It gets sent to the
- curl-announce, curl-library and curl-users mailing lists.
- - The security web page on the web site should get the new vulnerability
- mentioned.
- [1] = http://oss-security.openwall.org/wiki/mailing-lists/distros
- CURL-SECURITY (at haxx dot se)
- ------------------------------
- Who is on this list? There are a couple of criteria you must meet, and then we
- might ask you to join the list or you can ask to join it. It really isn't very
- formal. We basically only require that you have a long-term presence in the
- curl project and you have shown an understanding for the project and its way
- of working. You must've been around for a good while and you should have no
- plans in vanishing in the near future.
- We do not make the list of partipants public mostly because it tends to vary
- somewhat over time and a list somewhere will only risk getting outdated.
|