# This file is dual licensed under the terms of the Apache License, Version
# 2.0, and the BSD License. See the LICENSE file in the root of this repository
# for complete details.
from __future__ import absolute_import, division, print_function
import os
import sys
from _cffi_src.utils import (
build_ffi_for_binding, compiler_type, extra_link_args
)
def _get_openssl_libraries(platform):
if os.environ.get("CRYPTOGRAPHY_SUPPRESS_LINK_FLAGS", None):
return []
# OpenSSL goes by a different library name on different operating systems.
if platform == "win32" and compiler_type() == "msvc":
windows_link_legacy_openssl = os.environ.get(
"CRYPTOGRAPHY_WINDOWS_LINK_LEGACY_OPENSSL", None
)
if windows_link_legacy_openssl is None:
# Link against the 1.1.0 names
libs = ["libssl", "libcrypto"]
else:
# Link against the 1.0.2 and lower names
libs = ["libeay32", "ssleay32"]
return libs + ["advapi32", "crypt32", "gdi32", "user32", "ws2_32"]
else:
# darwin, linux, mingw all use this path
# In some circumstances, the order in which these libs are
# specified on the linker command-line is significant;
# libssl must come before libcrypto
# (http://marc.info/?l=openssl-users&m=135361825921871)
return ["ssl", "crypto"]
def _extra_compile_args(platform):
"""
We set -Wconversion args here so that we only do Wconversion checks on the
code we're compiling and not on cffi itself (as passing -Wconversion in
CFLAGS would do). We set no error on sign conversion because some
function signatures in OpenSSL have changed from long -> unsigned long
in the past. Since that isn't a precision issue we don't care.
When we drop support for CRYPTOGRAPHY_OPENSSL_LESS_THAN_110 we can
revisit this.
"""
if platform != "win32":
return ["-Wconversion", "-Wno-error=sign-conversion"]
else:
return []
ffi = build_ffi_for_binding(
module_name="_openssl",
module_prefix="_cffi_src.openssl.",
modules=[
# This goes first so we can define some cryptography-wide symbols.
"cryptography",
"aes",
"asn1",
"bignum",
"bio",
"cmac",
"cms",
"conf",
"crypto",
"ct",
"dh",
"dsa",
"ec",
"ecdh",
"ecdsa",
"engine",
"err",
"evp",
"fips",
"hmac",
"nid",
"objects",
"ocsp",
"opensslv",
"osrandom_engine",
"pem",
"pkcs12",
"rand",
"rsa",
"ssl",
"x509",
"x509name",
"x509v3",
"x509_vfy",
"pkcs7",
"callbacks",
],
libraries=_get_openssl_libraries(sys.platform),
# These args are passed here so that we only do Wconversion checks on the
# code we're compiling and not on cffi itself (as passing -Wconversion in
# CFLAGS would do). We set no error on sign convesrion because some
# function signatures in OpenSSL have changed from long -> unsigned long
# in the past. Since that isn't a precision issue we don't care.
# When we drop support for CRYPTOGRAPHY_OPENSSL_LESS_THAN_110 we can
# revisit this.
extra_compile_args=_extra_compile_args(sys.platform),
extra_link_args=extra_link_args(compiler_type()),
)
ers'>1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
Reviewing and merging patches
=============================
Everyone is encouraged to review open pull requests. We only ask that you try
and think carefully, ask questions and are `excellent to one another`_. Code
review is our opportunity to share knowledge, design ideas and make friends.
When reviewing a patch try to keep each of these concepts in mind:
Architecture
------------
* Is the proposed change being made in the correct place? Is it a fix in a
backend when it should be in the primitives?
Intent
------
* What is the change being proposed?
* Do we want this feature or is the bug they're fixing really a bug?
Implementation
--------------
* Does the change do what the author claims?
* Are there sufficient tests?
* Has it been documented?
* Will this change introduce new bugs?
Grammar and style
-----------------
These are small things that are not caught by the automated style checkers.
* Does a variable need a better name?
* Should this be a keyword argument?
Merge requirements
------------------
Because cryptography is so complex, and the implications of getting it wrong so
devastating, ``cryptography`` has a strict merge policy for committers:
* Patches must *never* be pushed directly to ``master``, all changes (even the
most trivial typo fixes!) must be submitted as a pull request.
* 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 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
backwards incompatible release of a dependency) no pull requests may be
merged until this is rectified.
* All merged patches must have 100% test coverage.
The purpose of these policies is to minimize the chances we merge a change
that jeopardizes our users' security.
.. _`excellent to one another`: https://speakerdeck.com/ohrite/better-code-review
|