From 61137bcd771f5e7e9f2f11625a75d15cb32b2816 Mon Sep 17 00:00:00 2001 From: Alex Gaynor Date: Mon, 27 Jan 2014 16:37:04 -0800 Subject: Reword for clarity --- docs/contributing.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'docs') diff --git a/docs/contributing.rst b/docs/contributing.rst index f4bc769c..184ba214 100644 --- a/docs/contributing.rst +++ b/docs/contributing.rst @@ -60,11 +60,11 @@ 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: -If a user will need to compare a user provided value with a computed value (for -example, checking a signature on something), there should be an API provided -which performs the check for the user in a secure way (for example, using a -constant time comparison), rather than requiring the user to perform the -comparison themselves. +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 +the verification in a secure way (for example, using a constant time +comparison), rather than requiring the user to perform the comparison +themselves. If it is incorrect to ignore the result of a method, it should raise an exception, and not return a boolean ``True``/``False`` flag. For example, a -- cgit v1.2.3