diff options
| author | Alex Gaynor <alex.gaynor@gmail.com> | 2014-02-08 13:41:36 -0800 |
|---|---|---|
| committer | Alex Gaynor <alex.gaynor@gmail.com> | 2014-02-08 13:41:36 -0800 |
| commit | ae17250910ef1bd660552ea0ba7d92020bde325b (patch) | |
| tree | 3eff61c22485d909dac3d1ae30fe938254c4b95b /docs/contributing.rst | |
| parent | 3d38f7a68b4ffc4cab920a82f1d6d225b906be22 (diff) | |
| parent | 63b3de2fa82729022d2c97e54b4c5e1a7ceff8f4 (diff) | |
| download | cryptography-ae17250910ef1bd660552ea0ba7d92020bde325b.tar.gz cryptography-ae17250910ef1bd660552ea0ba7d92020bde325b.tar.bz2 cryptography-ae17250910ef1bd660552ea0ba7d92020bde325b.zip | |
Merge pull request #579 from public/words
s/which/that/
Diffstat (limited to 'docs/contributing.rst')
| -rw-r--r-- | docs/contributing.rst | 8 |
1 files changed, 4 insertions, 4 deletions
diff --git a/docs/contributing.rst b/docs/contributing.rst index 7f4c77f4..87075638 100644 --- a/docs/contributing.rst +++ b/docs/contributing.rst @@ -22,7 +22,7 @@ devastating, ``cryptography`` has a strict code review policy: * A committer may *never* merge their own pull request, a second party must merge their changes. If multiple people work on a pull request, it must be merged by someone who did not work on it. -* A patch which breaks tests, or introduces regressions by changing or removing +* A patch that breaks tests, or introduces regressions by changing or removing existing tests should not be merged. Tests must always be passing on ``master``. * If somehow the tests get into a failing state on ``master`` (such as by a @@ -33,7 +33,7 @@ devastating, ``cryptography`` has a strict code review policy: :doc:`/changelog`. The purpose of these policies is to minimize the chances we merge a change -which jeopardizes our users' security. +that jeopardizes our users' security. If you believe you've identified a security issue in ``cryptography``, please follow the directions on the :doc:`security page </security>`. @@ -60,10 +60,10 @@ and make hard things possible". One of the perils of writing cryptographic code is that secure code looks just like insecure code, and its results are almost always indistinguishable. As a result ``cryptography`` has, as a design philosophy: "make it hard to do insecure things". Here are a few strategies for -API design which should be both followed, and should inspire other API choices: +API design that should be both followed, and should inspire other API choices: If it is necessary to compare a user provided value with a computed value (for -example, verifying a signature), there should be an API provided which performs +example, verifying a signature), there should be an API provided that performs the verification in a secure way (for example, using a constant time comparison), rather than requiring the user to perform the comparison themselves. |