security.rst 4.8 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115
  1. Security
  2. ========
  3. We take the security of ``cryptography`` seriously. The following are a set of
  4. policies we have adopted to ensure that security issues are addressed in a
  5. timely fashion.
  6. What is a security issue?
  7. -------------------------
  8. Anytime it's possible to write code using ``cryptography``'s public API which
  9. does not provide the guarantees that a reasonable developer would expect it to
  10. based on our documentation.
  11. That's a bit academic, but basically it means the scope of what we consider a
  12. vulnerability is broad, and we do not require a proof of concept or even a
  13. specific exploit, merely a reasonable threat model under which ``cryptography``
  14. could be attacked.
  15. To give a few examples of things we would consider security issues:
  16. * If a recipe, such as Fernet, made it easy for a user to bypass
  17. confidentiality or integrity with the public API (e.g. if the API let a user
  18. reuse nonces).
  19. * If, under any circumstances, we used a CSPRNG which wasn't fork-safe.
  20. * If ``cryptography`` used an API in an underlying C library and failed to
  21. handle error conditions safely.
  22. Examples of things we wouldn't consider security issues:
  23. * Offering ECB mode for symmetric encryption in the *Hazmat* layer. Though ECB
  24. is critically weak, it is documented as being weak in our documentation.
  25. * Using a variable time comparison somewhere, if it's not possible to
  26. articulate any particular program in which this would result in problematic
  27. information disclosure.
  28. In general, if you're unsure, we request that you to default to treating things
  29. as security issues and handling them sensitively, the worst thing that can
  30. happen is that we'll ask you to file a bug issue.
  31. Reporting a security issue
  32. --------------------------
  33. We ask that you do not report security issues to our normal GitHub issue
  34. tracker.
  35. If you believe you've identified a security issue with ``cryptography``, please
  36. report it to ``alex.gaynor@gmail.com``. Messages may be optionally encrypted
  37. with PGP using key fingerprint
  38. ``F7FC 698F AAE2 D2EF BECD E98E D1B3 ADC0 E023 8CA6`` (this public key is
  39. available from most commonly-used key servers).
  40. Once you've submitted an issue via email, you should receive an acknowledgment
  41. within 48 hours, and depending on the action to be taken, you may receive
  42. further follow-up emails.
  43. Supported Versions
  44. ------------------
  45. At any given time, we will provide security support for the `master`_ branch
  46. as well as the most recent release.
  47. New releases for OpenSSL updates
  48. --------------------------------
  49. As of version 0.5, ``cryptography`` statically links OpenSSL on Windows, and as
  50. of version 1.0.1 on OS X, to ease installation. Due to this, ``cryptography``
  51. will release a new version whenever OpenSSL has a security or bug fix release to
  52. avoid shipping insecure software.
  53. Like all our other releases, this will be announced on the mailing list and we
  54. strongly recommend that you upgrade as soon as possible.
  55. Disclosure Process
  56. ------------------
  57. Our process for taking a security issue from private discussion to public
  58. disclosure involves multiple steps.
  59. Approximately one week before full public disclosure, we will send advance
  60. notification of the issue to a list of people and organizations, primarily
  61. composed of operating-system vendors and other distributors of
  62. ``cryptography``. This notification will consist of an email message
  63. containing:
  64. * A full description of the issue and the affected versions of
  65. ``cryptography``.
  66. * The steps we will be taking to remedy the issue.
  67. * The patches, if any, that will be applied to ``cryptography``.
  68. * The date on which the ``cryptography`` team will apply these patches, issue
  69. new releases, and publicly disclose the issue.
  70. Simultaneously, the reporter of the issue will receive notification of the date
  71. on which we plan to take the issue public.
  72. On the day of disclosure, we will take the following steps:
  73. * Apply the relevant patches to the ``cryptography`` repository. The commit
  74. messages for these patches will indicate that they are for security issues,
  75. but will not describe the issue in any detail; instead, they will warn of
  76. upcoming disclosure.
  77. * Issue the relevant releases.
  78. * Post a notice to the cryptography mailing list that describes the issue in
  79. detail, point to the new release and crediting the reporter of the issue.
  80. If a reported issue is believed to be particularly time-sensitive – due to a
  81. known exploit in the wild, for example – the time between advance notification
  82. and public disclosure may be shortened considerably.
  83. The list of people and organizations who receives advanced notification of
  84. security issues is not and will not be made public. This list generally
  85. consists of high profile downstream distributors and is entirely at the
  86. discretion of the ``cryptography`` team.
  87. .. _`master`: https://github.com/pyca/cryptography