diff options
Diffstat (limited to 'docs/security.rst')
| -rw-r--r-- | docs/security.rst | 92 |
1 files changed, 52 insertions, 40 deletions
diff --git a/docs/security.rst b/docs/security.rst index 50253457..8cdd2d11 100644 --- a/docs/security.rst +++ b/docs/security.rst @@ -5,6 +5,47 @@ We take the security of ``cryptography`` seriously. The following are a set of policies we have adopted to ensure that security issues are addressed in a timely fashion. +Infrastructure +-------------- + +In addition to ``cryptography``'s code, we're also concerned with the security +of the infrastructure we run (primarily ``cryptography.io``). If you discover +a security vulnerability in our infrastructure, we ask you to report it using +the same procedure. + +What is a security issue? +------------------------- + +Anytime it's possible to write code using ``cryptography``'s public API which +does not provide the guarantees that a reasonable developer would expect it to +based on our documentation. + +That's a bit academic, but basically it means the scope of what we consider a +vulnerability is broad, and we do not require a proof of concept or even a +specific exploit, merely a reasonable threat model under which ``cryptography`` +could be attacked. + +To give a few examples of things we would consider security issues: + +* If a recipe, such as Fernet, made it easy for a user to bypass + confidentiality or integrity with the public API (e.g. if the API let a user + reuse nonces). +* If, under any circumstances, we used a CSPRNG which wasn't fork-safe. +* If ``cryptography`` used an API in an underlying C library and failed to + handle error conditions safely. + +Examples of things we wouldn't consider security issues: + +* Offering ECB mode for symmetric encryption in the *Hazmat* layer. Though ECB + is critically weak, it is documented as being weak in our documentation. +* Using a variable time comparison somewhere, if it's not possible to + articulate any particular program in which this would result in problematic + information disclosure. + +In general, if you're unsure, we request that you to default to treating things +as security issues and handling them sensitively, the worst thing that can +happen is that we'll ask you to file a public issue. + Reporting a security issue -------------------------- @@ -14,7 +55,7 @@ tracker. If you believe you've identified a security issue with ``cryptography``, please report it to ``alex.gaynor@gmail.com``. Messages may be optionally encrypted with PGP using key fingerprint -``E27D 4AA0 1651 72CB C5D2 AF2B 125F 5C67 DFE9 4084`` (this public key is +``F7FC 698F AAE2 D2EF BECD E98E D1B3 ADC0 E023 8CA6`` (this public key is available from most commonly-used key servers). Once you've submitted an issue via email, you should receive an acknowledgment @@ -25,12 +66,13 @@ Supported Versions ------------------ At any given time, we will provide security support for the `master`_ branch -as well as the 2 most recent releases. +as well as the most recent release. New releases for OpenSSL updates -------------------------------- -As of version 0.5, ``cryptography`` statically links OpenSSL on Windows to ease +As of versions 0.5, 1.0.1, and 2.0.0, ``cryptography`` statically links OpenSSL +in binary distributions for Windows, macOS, and Linux respectively, to ease installation. Due to this, ``cryptography`` will release a new version whenever OpenSSL has a security or bug fix release to avoid shipping insecure software. @@ -40,42 +82,12 @@ strongly recommend that you upgrade as soon as possible. Disclosure Process ------------------ -Our process for taking a security issue from private discussion to public -disclosure involves multiple steps. - -Approximately one week before full public disclosure, we will send advance -notification of the issue to a list of people and organizations, primarily -composed of operating-system vendors and other distributors of -``cryptography``. This notification will consist of an email message -containing: - -* A full description of the issue and the affected versions of - ``cryptography``. -* The steps we will be taking to remedy the issue. -* The patches, if any, that will be applied to ``cryptography``. -* The date on which the ``cryptography`` team will apply these patches, issue - new releases, and publicly disclose the issue. - -Simultaneously, the reporter of the issue will receive notification of the date -on which we plan to take the issue public. - -On the day of disclosure, we will take the following steps: - -* Apply the relevant patches to the ``cryptography`` repository. The commit - messages for these patches will indicate that they are for security issues, - but will not describe the issue in any detail; instead, they will warn of - upcoming disclosure. -* Issue the relevant releases. -* Post a notice to the cryptography mailing list that describes the issue in - detail, point to the new release and crediting the reporter of the issue. - -If a reported issue is believed to be particularly time-sensitive – due to a -known exploit in the wild, for example – the time between advance notification -and public disclosure may be shortened considerably. - -The list of people and organizations who receives advanced notification of -security issues is not and will not be made public. This list generally -consists of high profile downstream distributors and is entirely at the -discretion of the ``cryptography`` team. +When we become aware of a security bug in ``cryptography``, we will endeavor to +fix it and issue a release as quickly as possible. We will generally issue a new +release for any security issue. + +The steps for issuing a security release are described in our +:doc:`/doing-a-release` documentation. + .. _`master`: https://github.com/pyca/cryptography |