From 63b3de2fa82729022d2c97e54b4c5e1a7ceff8f4 Mon Sep 17 00:00:00 2001 From: Alex Stapleton Date: Sat, 8 Feb 2014 09:43:16 +0000 Subject: s/which/that/ Which is usually for descriptive clauses in technical writing, while that is restrictive. Most of the time we are being being restrictive. --- docs/contributing.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'docs/contributing.rst') diff --git a/docs/contributing.rst b/docs/contributing.rst index 74b854bd..86708836 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 `. @@ -58,10 +58,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. -- cgit v1.2.3