Return to SECURITY-PROCESS.md CVS log

Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / curl / docs

Annotation of embedaddon/curl/docs/SECURITY-PROCESS.md, revision 1.1.1.1

1.1       misho       1: curl security process
                      2: =====================
                      3: 
                      4: This document describes how security vulnerabilities should be handled in the
                      5: curl project.
                      6: 
                      7: Publishing Information
                      8: ----------------------
                      9: 
                     10: All known and public curl or libcurl related vulnerabilities are listed on
                     11: [the curl web site security page](https://curl.haxx.se/docs/security.html).
                     12: 
                     13: Security vulnerabilities **should not** be entered in the project's public bug
                     14: tracker.
                     15: 
                     16: Vulnerability Handling
                     17: ----------------------
                     18: 
                     19: The typical process for handling a new security vulnerability is as follows.
                     20: 
                     21: No information should be made public about a vulnerability until it is
                     22: formally announced at the end of this process. That means, for example that a
                     23: bug tracker entry must NOT be created to track the issue since that will make
                     24: the issue public and it should not be discussed on any of the project's public
                     25: mailing lists. Also messages associated with any commits should not make any
                     26: reference to the security nature of the commit if done prior to the public
                     27: announcement.
                     28: 
                     29: - The person discovering the issue, the reporter, reports the vulnerability on
                     30:   [https://hackerone.com/curl](https://hackerone.com/curl). Issues filed there
                     31:   reach a handful of selected and trusted people.
                     32: 
                     33: - Messages that do not relate to the reporting or managing of an undisclosed
                     34:   security vulnerability in curl or libcurl are ignored and no further action
                     35:   is required.
                     36: 
                     37: - A person in the security team responds to the original report to acknowledge
                     38:   that a human has seen the report.
                     39: 
                     40: - The security team investigates the report and either rejects it or accepts
                     41:   it.
                     42: 
                     43: - If the report is rejected, the team writes to the reporter to explain why.
                     44: 
                     45: - If the report is accepted, the team writes to the reporter to let him/her
                     46:   know it is accepted and that they are working on a fix.
                     47: 
                     48: - The security team discusses the problem, works out a fix, considers the
                     49:   impact of the problem and suggests a release schedule. This discussion
                     50:   should involve the reporter as much as possible.
                     51: 
                     52: - The release of the information should be "as soon as possible" and is most
                     53:   often synchronized with an upcoming release that contains the fix. If the
                     54:   reporter, or anyone else involved, thinks the next planned release is too
                     55:   far away, then a separate earlier release should be considered.
                     56: 
                     57: - Write a security advisory draft about the problem that explains what the
                     58:   problem is, its impact, which versions it affects, solutions or workarounds,
                     59:   when the release is out and make sure to credit all contributors properly.
                     60:   Figure out the CWE (Common Weakness Enumeration) number for the flaw.
                     61: 
                     62: - Request a CVE number from
                     63:   [HackerOne](https://docs.hackerone.com/programs/cve-requests.html)
                     64: 
                     65: - Consider informing
                     66:   [distros@openwall](https://oss-security.openwall.org/wiki/mailing-lists/distros)
                     67:   to prepare them about the upcoming public security vulnerability
                     68:   announcement - attach the advisory draft for information. Note that
                     69:   'distros' won't accept an embargo longer than 14 days and they do not care
                     70:   for Windows-specific flaws.
                     71: 
                     72: - Update the "security advisory" with the CVE number.
                     73: 
                     74: - The security team commits the fix in a private branch. The commit message
                     75:   should ideally contain the CVE number. This fix is usually also distributed
                     76:   to the 'distros' mailing list to allow them to use the fix prior to the
                     77:   public announcement.
                     78: 
                     79: - No more than 48 hours before the release, the private branch is merged into
                     80:   the master branch and pushed. Once pushed, the information is accessible to
                     81:   the public and the actual release should follow suit immediately afterwards.
                     82:   The time between the push and the release is used for final tests and
                     83:   reviews.
                     84: 
                     85: - The project team creates a release that includes the fix.
                     86: 
                     87: - The project team announces the release and the vulnerability to the world in
                     88:   the same manner we always announce releases. It gets sent to the
                     89:   curl-announce, curl-library and curl-users mailing lists.
                     90: 
                     91: - The security web page on the web site should get the new vulnerability
                     92:   mentioned.
                     93: 
                     94: curl-security (at haxx dot se)
                     95: ------------------------------
                     96: 
                     97: This is a private mailing list for discussions on and about curl security
                     98: issues.
                     99: 
                    100: Who is on this list? There are a couple of criteria you must meet, and then we
                    101: might ask you to join the list or you can ask to join it. It really isn't very
                    102: formal. We basically only require that you have a long-term presence in the
                    103: curl project and you have shown an understanding for the project and its way
                    104: of working. You must've been around for a good while and you should have no
                    105: plans in vanishing in the near future.
                    106: 
                    107: We do not make the list of participants public mostly because it tends to vary
                    108: somewhat over time and a list somewhere will only risk getting outdated.
                    109: 
                    110: Publishing Security Advisories
                    111: ------------------------------
                    112: 
                    113: 1. Write up the security advisory, using markdown syntax. Use the same
                    114:    subtitles as last time to maintain consistency.
                    115: 
                    116: 2. Name the advisory file after the allocated CVE id.
                    117: 
                    118: 3. Add a line on the top of the array in `curl-www/docs/vuln.pm'.
                    119: 
                    120: 4. Put the new advisory markdown file in the curl-www/docs/ directory. Add it
                    121:    to the git repo.
                    122: 
                    123: 5. Run `make` in your local web checkout and verify that things look fine.
                    124: 
                    125: 6. On security advisory release day, push the changes on the curl-www
                    126:    repository's remote master branch.
                    127: 
                    128: Bug Bounty
                    129: ----------
                    130: 
                    131: See [BUG-BOUNTY](https://curl.haxx.se/docs/bugbounty.html) for details on the
                    132: bug bounty program.