security.rst 3.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293
  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. Infrastructure
  7. --------------
  8. In addition to ``cryptography``'s code, we're also concerned with the security
  9. of the infrastructure we run (primarily ``cryptography.io``). If you discover
  10. a security vulnerability in our infrastructure, we ask you to report it using
  11. the same procedure.
  12. What is a security issue?
  13. -------------------------
  14. Anytime it's possible to write code using ``cryptography``'s public API which
  15. does not provide the guarantees that a reasonable developer would expect it to
  16. based on our documentation.
  17. That's a bit academic, but basically it means the scope of what we consider a
  18. vulnerability is broad, and we do not require a proof of concept or even a
  19. specific exploit, merely a reasonable threat model under which ``cryptography``
  20. could be attacked.
  21. To give a few examples of things we would consider security issues:
  22. * If a recipe, such as Fernet, made it easy for a user to bypass
  23. confidentiality or integrity with the public API (e.g. if the API let a user
  24. reuse nonces).
  25. * If, under any circumstances, we used a CSPRNG which wasn't fork-safe.
  26. * If ``cryptography`` used an API in an underlying C library and failed to
  27. handle error conditions safely.
  28. Examples of things we wouldn't consider security issues:
  29. * Offering ECB mode for symmetric encryption in the *Hazmat* layer. Though ECB
  30. is critically weak, it is documented as being weak in our documentation.
  31. * Using a variable time comparison somewhere, if it's not possible to
  32. articulate any particular program in which this would result in problematic
  33. information disclosure.
  34. In general, if you're unsure, we request that you to default to treating things
  35. as security issues and handling them sensitively, the worst thing that can
  36. happen is that we'll ask you to file a public issue.
  37. Reporting a security issue
  38. --------------------------
  39. We ask that you do not report security issues to our normal GitHub issue
  40. tracker.
  41. If you believe you've identified a security issue with ``cryptography``, please
  42. report it to ``alex.gaynor@gmail.com``. Messages may be optionally encrypted
  43. with PGP using key fingerprint
  44. ``F7FC 698F AAE2 D2EF BECD E98E D1B3 ADC0 E023 8CA6`` (this public key is
  45. available from most commonly-used key servers).
  46. Once you've submitted an issue via email, you should receive an acknowledgment
  47. within 48 hours, and depending on the action to be taken, you may receive
  48. further follow-up emails.
  49. Supported Versions
  50. ------------------
  51. At any given time, we will provide security support for the `master`_ branch
  52. as well as the most recent release.
  53. New releases for OpenSSL updates
  54. --------------------------------
  55. As of versions 0.5, 1.0.1, and 2.0.0, ``cryptography`` statically links OpenSSL
  56. on Windows, macOS, and Linux respectively, to ease installation. Due to this,
  57. ``cryptography`` will release a new version whenever OpenSSL has a security or
  58. bug fix release to avoid shipping insecure software.
  59. Like all our other releases, this will be announced on the mailing list and we
  60. strongly recommend that you upgrade as soon as possible.
  61. Disclosure Process
  62. ------------------
  63. When we become aware of a security bug in ``cryptography``, we will endeavor to
  64. fix it and issue a release as quickly as possible. We will generally issue a new
  65. release for any security issue.
  66. The steps for issuing a security release are described in our
  67. :doc:`/doing-a-release` documentation.
  68. .. _`master`: https://github.com/pyca/cryptography