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     ! 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.