internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: pyca/cryptography

Issue:
utils.int_from_bytes gives incorrect answers when passed "builtins.bytes" in python 2.7
```
$ mkvirtualenv repro
$ python --version
Python 2.7.12
$ pip install cryptography future
$ python

from cryptography import utils
from builtins import bytes
x = bytes.fromhex('deadbeef')
y = utils.int_from_bytes(x, 'big')
hex(y)
'0x6227deadbeef27'
```

The reason this happens is that `int_from_bytes` (in py27 mode) casts the passed-in value to `bytes`, which, in py27 mode, is an alias for `str`. Passing a `builtins.bytes` value to `str` somewhat insanely wraps the string with `b'` and `'`. These then get parsed by the rest of `int_from_bytes` as if they were part of the original byte string.

I think this is particularly unfortunate since all the "cryptography" functions say they accept and return `bytes` in their docstrings. Ideally it'd be compatible with all three definitions of `bytes`: the py27 alias to `str`, the one from "future", and the py3 one.


Discussion:

Resolving patch:
diff --git a/src/cryptography/utils.py b/src/cryptography/utils.py
--- a/src/cryptography/utils.py
+++ b/src/cryptography/utils.py
@@ -57,8 +57,7 @@ def int_from_bytes(data, byteorder, signed=False):
         assert byteorder == 'big'
         assert not signed
 
-        # call bytes() on data to allow the use of bytearrays
-        return int(bytes(data).encode('hex'), 16)
+        return int(binascii.hexlify(data), 16)
 
 
 if hasattr(int, "to_bytes"):


Test patch:
diff --git a/tests/test_cryptography_utils.py b/tests/test_cryptography_utils.py
--- a/tests/test_cryptography_utils.py
+++ b/tests/test_cryptography_utils.py
@@ -11,6 +11,8 @@
 
 def test_int_from_bytes_bytearray():
     assert utils.int_from_bytes(bytearray(b"\x02\x10"), "big") == 528
+    with pytest.raises(TypeError):
+        utils.int_from_bytes(["list", "is", "not", "bytes"], "big")
 
 
 class TestCachedProperty(object):
Repository: pyca/cryptography

Issue:
Per-call memory growth with derive_private_key
Would unbounded memory growth with repeated calls to derive_private_key be expected behavior, or am I doing something wrong or unsupported?  Behavior is the same across Ubuntu and Mac and multiple python versions, all with Cryptography 2.1.4, as noted below. 

This snippet experiences memory growth with each call to derive_private_key (with or without the "del sk" line). I tried some python profilers but can't track it down.

```
from cryptography.hazmat.primitives.asymmetric.ec import SECP256K1, derive_private_key
from cryptography.hazmat.backends import default_backend
DEFAULT_BACKEND = default_backend()
SECP256K1 = SECP256K1()
for i in range(0,10000000):
	sk = derive_private_key(1, SECP256K1, DEFAULT_BACKEND)
	del sk
```
**Platforms**
Linux ubuntu 4.13.0-32-generic #35-Ubuntu SMP Thu Jan 25 09:13:46 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Python 2.7.14 (default, Sep 23 2017, 22:06:14) [GCC 7.2.0] on linux2
Python 3.6.3 (default, Oct  3 2017, 21:45:48) [GCC 7.2.0] on linux
Cryptography 2.1.4
OpenSSL 1.0.2g  1 Mar 2016
  
macOS 10.12.6 (16G1114) Darwin 16.7.0
Python 2.7.10 (default, Feb  7 2017, 00:08:15) [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
Python 3.6.3 (default, Oct  4 2017, 06:09:15) [GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.37)] on darwin
Cryptography 2.1.4
OpenSSL 1.0.2n  7 Dec 2017

Thank you.



Discussion:

Resolving patch:
diff --git a/src/cryptography/hazmat/backends/openssl/backend.py b/src/cryptography/hazmat/backends/openssl/backend.py
--- a/src/cryptography/hazmat/backends/openssl/backend.py
+++ b/src/cryptography/hazmat/backends/openssl/backend.py
@@ -1409,8 +1409,9 @@ def derive_elliptic_curve_private_key(self, private_value, curve):
 
         res = self._lib.EC_KEY_set_public_key(ec_cdata, point)
         self.openssl_assert(res == 1)
-        res = self._lib.EC_KEY_set_private_key(
-            ec_cdata, self._int_to_bn(private_value))
+        private = self._int_to_bn(private_value)
+        private = self._ffi.gc(private, self._lib.BN_clear_free)
+        res = self._lib.EC_KEY_set_private_key(ec_cdata, private)
         self.openssl_assert(res == 1)
 
         evp_pkey = self._ec_cdata_to_evp_pkey(ec_cdata)


Test patch:
diff --git a/tests/hazmat/backends/test_openssl_memleak.py b/tests/hazmat/backends/test_openssl_memleak.py
--- a/tests/hazmat/backends/test_openssl_memleak.py
+++ b/tests/hazmat/backends/test_openssl_memleak.py
@@ -214,3 +214,11 @@ def func():
                 )
             ).private_key(backend)
         """))
+
+    def test_ec_derive_private_key(self):
+        assert_no_memory_leaks(textwrap.dedent("""
+        def func():
+            from cryptography.hazmat.backends.openssl import backend
+            from cryptography.hazmat.primitives.asymmetric import ec
+            ec.derive_private_key(1, ec.SECP256R1(), backend)
+        """))
Repository: pyca/cryptography

Issue:
SubjectAlternativeName() should not allow to pass empty list



Discussion:

Resolving patch:
diff --git a/src/cryptography/x509/extensions.py b/src/cryptography/x509/extensions.py
--- a/src/cryptography/x509/extensions.py
+++ b/src/cryptography/x509/extensions.py
@@ -1160,6 +1160,9 @@ def __hash__(self):
 class GeneralNames(object):
     def __init__(self, general_names):
         general_names = list(general_names)
+        if len(general_names) == 0:
+            raise ValueError("Must supply at least one general name")
+
         if not all(isinstance(x, GeneralName) for x in general_names):
             raise TypeError(
                 "Every item in the general_names list must be an "


Test patch:
diff --git a/tests/x509/test_x509_ext.py b/tests/x509/test_x509_ext.py
--- a/tests/x509/test_x509_ext.py
+++ b/tests/x509/test_x509_ext.py
@@ -2052,6 +2052,10 @@ def test_invalid_general_names(self):
                 [x509.DNSName(u"cryptography.io"), "invalid"]
             )
 
+    def test_does_not_allow_empty_list(self):
+        with pytest.raises(ValueError):
+            x509.GeneralNames([])
+
     def test_repr(self):
         gns = x509.GeneralNames(
             [
Repository: pyca/cryptography

Issue:
Figure out how to fix docs build on rtd
It appears to be running into https://github.com/sphinx-doc/sphinx/issues/3976


Discussion:

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -296,12 +296,14 @@ def run_tests(self):
         ":platform_python_implementation != 'PyPy'": ["cffi >= 1.7"],
 
         "test": test_requirements,
+        "docs": [
+            "sphinx >= 1.6.5",
+            "sphinx_rtd_theme",
+        ],
         "docstest": [
             "doc8",
             "pyenchant >= 1.6.11",
             "readme_renderer >= 16.0",
-            "sphinx >= 1.6.5",
-            "sphinx_rtd_theme",
             "sphinxcontrib-spelling >= 4.0.1",
         ],
         "pep8test": [


Test patch:
Repository: pyca/cryptography

Issue:
Some OpenSSL bignum arithmetic operations are not in constant time
### What's wrong:
1. Some arithmetic operations exposed in the [OpenSSL bignum binding](https://github.com/pyca/cryptography/blob/master/src/_cffi_src/openssl/bignum.py) are not in constant time.
2. These functions are specifically:
    1. `BN_div`
    2. `BN_mod_inverse`
    3. `BN_mod_exp`

### How to resolve:
1. The OpenSSL solution to this is to call `BN_set_flags` on the secret BIGNUM and set the `BN_FLG_CONSTTIME` flag. [The OpenSSL docs reference this here.](https://github.com/openssl/openssl/blob/master/include/openssl/bn.h#L61)
2. Expose the needed operations:
    1. `BN_MONT_CTX` operations.
    2. `BN_mod_exp_mont`, and `BN_mod_exp_mont_consttime` 
    3. `BN_set_flags`, `BN_get_flags`, and the `BN_FLG_CONSTTIME` flag.

### Notes:
1. Cryptography.io isn't affected by these timing issues. I have clarified with @alex and @reaperhulk.
2. If you are a downstream user utilizing these operations on private/secret values, then _you are affected_.


Discussion:
@tuxxy Are you planning to send a PR to expose the newer functions? Other than that, there's nothing actionable for the project although it's useful to have this issue to point at for users who may be poking around in the dark, ichor-y heart of the system.
@reaperhulk Yes, I do intend on putting out a PR shortly.

Resolving patch:
diff --git a/src/_cffi_src/openssl/bignum.py b/src/_cffi_src/openssl/bignum.py
--- a/src/_cffi_src/openssl/bignum.py
+++ b/src/_cffi_src/openssl/bignum.py
@@ -10,11 +10,17 @@
 
 TYPES = """
 typedef ... BN_CTX;
+typedef ... BN_MONT_CTX;
 typedef ... BIGNUM;
 typedef int... BN_ULONG;
 """
 
 FUNCTIONS = """
+#define BN_FLG_CONSTTIME ...
+
+void BN_set_flags(BIGNUM *, int);
+int BN_get_flags(const BIGNUM *, int);
+
 BIGNUM *BN_new(void);
 void BN_free(BIGNUM *);
 void BN_clear_free(BIGNUM *);
@@ -29,6 +35,10 @@
 BIGNUM *BN_CTX_get(BN_CTX *);
 void BN_CTX_end(BN_CTX *);
 
+BN_MONT_CTX *BN_MONT_CTX_new(void);
+int BN_MONT_CTX_set(BN_MONT_CTX *, BIGNUM *, BN_CTX *);
+void BN_MONT_CTX_free(BN_MONT_CTX *);
+
 BIGNUM *BN_copy(BIGNUM *, const BIGNUM *);
 BIGNUM *BN_dup(const BIGNUM *);
 
@@ -63,6 +73,10 @@
 int BN_exp(BIGNUM *, const BIGNUM *, const BIGNUM *, BN_CTX *);
 int BN_mod_exp(BIGNUM *, const BIGNUM *, const BIGNUM *, const BIGNUM *,
                BN_CTX *);
+int BN_mod_exp_mont(BIGNUM *, const BIGNUM *, const BIGNUM *, const BIGNUM *,
+                    BN_CTX *, BN_MONT_CTX *);
+int BN_mod_exp_mont_consttime(BIGNUM *, const BIGNUM *, const BIGNUM *,
+                              const BIGNUM *, BN_CTX *, BN_MONT_CTX *);
 int BN_gcd(BIGNUM *, const BIGNUM *, const BIGNUM *, BN_CTX *);
 BIGNUM *BN_mod_inverse(BIGNUM *, const BIGNUM *, const BIGNUM *, BN_CTX *);
 


Test patch:
Repository: pyca/cryptography

Issue:
[Feature request] expose BIGNUM prime methods
For our research (@Tribler) we use OpenSSL's `BN_generate_prime_ex` and `BN_is_prime_ex` through custom bindings. Is this something you would want to support in your bindings (hazmat backend)?

If you're interested, I can turn https://github.com/qstokkink/cryptography/commit/31d2bc21e60c6842be2927aa576834b3cf2bf6a4 into a polished PR.


Discussion:
These are stable functions that exist in all our supported versions (as well as boringssl, a target we would like to support). I'm not opposed to adding them to our bindings. However, some caveats:

* I'm not convinced we want to add any methods to the Python layer that use these.
* If we're not a direct consumer of these functions then when we do cleanup PRs we have to use our git history/fallible human memories to figure out why they were bound. This is a bit of a pain and means we can't 100% guarantee we won't remove them in the future (although we haven't done that to a consumer yet)
Thanks for the response, I'll just PR the C bindings then without the Python layer.
I'll also add some inline comments to the bindings that link to our project (or this issue).

Resolving patch:
diff --git a/src/_cffi_src/openssl/bignum.py b/src/_cffi_src/openssl/bignum.py
--- a/src/_cffi_src/openssl/bignum.py
+++ b/src/_cffi_src/openssl/bignum.py
@@ -72,6 +72,12 @@
 int BN_num_bytes(const BIGNUM *);
 
 int BN_mod(BIGNUM *, const BIGNUM *, const BIGNUM *, BN_CTX *);
+
+/* The following 3 prime methods are exposed for Tribler. */
+int BN_generate_prime_ex(BIGNUM *, int, int, const BIGNUM *,
+                         const BIGNUM *, BN_GENCB *);
+int BN_is_prime_ex(const BIGNUM *, int, BN_CTX *, BN_GENCB *);
+const int BN_prime_checks_for_size(int);
 """
 
 CUSTOMIZATIONS = """


Test patch:
Repository: pyca/cryptography

Issue:
incorrect key_size of sect571r1
Hello!

https://github.com/pyca/cryptography/blob/17c8f126c7c7d5ce886112a6e924277a7b203f25/src/cryptography/hazmat/primitives/asymmetric/ec.py#L138

The value there should be 570. From [the standard](http://www.secg.org/sec2-v2.pdf) the order of the published generator is 

```py
>>> order = 0x03FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE661CE18FF55987308059B186823851EC7DD9CA1161DE93D5174D66E8382E9BB2FE84E47
>>> print(len(bin(order))-2)
570
```


Discussion:
Great catch. It should be possible to write a test that'd catch that by with `from_encoded_point` which uses the `key_size` IIRC.
Thanks for the report! `key_size` is, unfortunately, nonsense. As you guessed it closely approximates group order, but is really just "whatever number is in the name". https://github.com/pyca/cryptography/issues/1478 originally reported this but we didn't really address the mistake for EC.
~I see that now, this one also has a completely wrong value according to [spec](http://www.secg.org/SEC2-Ver-1.0.pdf):~

https://github.com/pyca/cryptography/blob/17c8f126c7c7d5ce886112a6e924277a7b203f25/src/cryptography/hazmat/primitives/asymmetric/ec.py#L204

```
>>> len(bin(0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC7634D81F4372DDF581A0DB248B0A77AECEC196ACCC52))-2
372
```
Actually, 384 is the right size. I was missing a few chars from copy/pasting from the pdf

Resolving patch:
diff --git a/src/cryptography/hazmat/primitives/asymmetric/ec.py b/src/cryptography/hazmat/primitives/asymmetric/ec.py
--- a/src/cryptography/hazmat/primitives/asymmetric/ec.py
+++ b/src/cryptography/hazmat/primitives/asymmetric/ec.py
@@ -135,7 +135,7 @@ def verify(self, signature, data, signature_algorithm):
 @utils.register_interface(EllipticCurve)
 class SECT571R1(object):
     name = "sect571r1"
-    key_size = 571
+    key_size = 570
 
 
 @utils.register_interface(EllipticCurve)


Test patch:
Repository: pyca/cryptography

Issue:
Add PEP 518 pyproject.toml



Discussion:
ITYM ``pyproject.toml``.
Uhhh, yes.
FWIW, I think this is all you need:


```toml
[build-system]
requires = [
    "setuptools",
    "wheel",
    "cffi>=1.4.1; platform_python_implementation != 'PyPy'",
]
```

Sadly, ``pip install .`` currently doesn't work with that (completely ignores it) until https://github.com/pypa/pip/pull/4501 lands.
Sweet, as soon as pip is released we will land that :D
FWIW I just tested that pip branch with that file (also modifying ``setup.cfg`` to block setuptools from ever touching the network, and I get:

```
$ env LDFLAGS="-L$(brew --prefix openssl@1.1)/lib" CFLAGS="-I$(brew --prefix openssl@1.1)/include" pip install ~p/cryptography
Processing /Users/dstufft/projects/cryptography
Collecting idna>=2.1 (from cryptography==1.9.dev1)
  Using cached idna-2.5-py2.py3-none-any.whl
Collecting asn1crypto>=0.21.0 (from cryptography==1.9.dev1)
  Using cached asn1crypto-0.22.0-py2.py3-none-any.whl
Requirement already satisfied: six>=1.4.1 in ./lib/python3.6/site-packages (from cryptography==1.9.dev1) (1.10.0)
Requirement already satisfied: setuptools>=20.5 in ./lib/python3.6/site-packages (from cryptography==1.9.dev1) (35.0.2)
Collecting cffi>=1.4.1 (from cryptography==1.9.dev1)
  Using cached cffi-1.10.0-cp36-cp36m-macosx_10_6_intel.whl
Requirement already satisfied: packaging>=16.8 in ./lib/python3.6/site-packages (from setuptools>=20.5->cryptography==1.9.dev1) (16.8)
Requirement already satisfied: appdirs>=1.4.0 in ./lib/python3.6/site-packages (from setuptools>=20.5->cryptography==1.9.dev1) (1.4.3)
Collecting pycparser (from cffi>=1.4.1->cryptography==1.9.dev1)
Requirement already satisfied: pyparsing in ./lib/python3.6/site-packages (from packaging>=16.8->setuptools>=20.5->cryptography==1.9.dev1) (2.2.0)
Building wheels for collected packages: cryptography
  Installing build dependencies ... done
  Running setup.py bdist_wheel for cryptography ... done
  Stored in directory: /var/folders/14/9jkprxq17f30vp_2wbfw79780000gn/T/tmps955pcem-pip-ephem-cache/wheels/a8/29/90/775e7c4a3137021374729262f2383c91e0f260ac0d600f85d9
Successfully built cryptography
Installing collected packages: idna, asn1crypto, pycparser, cffi, cryptography
Successfully installed asn1crypto-0.22.0 cffi-1.10.0 cryptography-1.9.dev1 idna-2.5 pycparser-2.17
```

So it appears to work too!
@dstufft if we land this before pip x is released, is it guaranteed that this API won't break, or should we wait until pip x is released?
@alex It might make sense to wait. It *shouldn't* change, but who knows. Probably ought to test it at least.
@dstufft gonna send a PR with this, but won't merge it until you promise promise promise it's final. PS please release pip x it's going to be so good :D

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -43,6 +43,7 @@
 
 VECTORS_DEPENDENCY = "cryptography_vectors=={0}".format(about['__version__'])
 
+# `setup_requirements` must be kept in sync with `pyproject.toml`
 setup_requirements = ["cffi>=1.7,!=1.11.3"]
 
 if platform.python_implementation() == "PyPy":


Test patch:
Repository: pyca/cryptography

Issue:
More descriptive error msg for certificate loading
When we fail to load a PEM certificate we do this: https://github.com/pyca/cryptography/blob/master/src/cryptography/hazmat/backends/openssl/backend.py#L1151

Given that people occasionally attempt to load valid certs that don't have proper line wrapping (see: https://github.com/pyca/cryptography/issues/4487 and https://github.com/pyca/cryptography/issues/4085) should we alter the text to say something about how what a valid PEM looks like and that they should check their cert?


Discussion:

Resolving patch:
diff --git a/src/cryptography/hazmat/backends/openssl/backend.py b/src/cryptography/hazmat/backends/openssl/backend.py
--- a/src/cryptography/hazmat/backends/openssl/backend.py
+++ b/src/cryptography/hazmat/backends/openssl/backend.py
@@ -1141,7 +1141,10 @@ def load_pem_x509_certificate(self, data):
         )
         if x509 == self._ffi.NULL:
             self._consume_errors()
-            raise ValueError("Unable to load certificate")
+            raise ValueError(
+                "Unable to load certificate. See https://cryptography.io/en/la"
+                "test/faq/#why-can-t-i-import-my-pem-file for more details."
+            )
 
         x509 = self._ffi.gc(x509, self._lib.X509_free)
         return _Certificate(self, x509)
@@ -1163,7 +1166,10 @@ def load_pem_x509_crl(self, data):
         )
         if x509_crl == self._ffi.NULL:
             self._consume_errors()
-            raise ValueError("Unable to load CRL")
+            raise ValueError(
+                "Unable to load CRL. See https://cryptography.io/en/la"
+                "test/faq/#why-can-t-i-import-my-pem-file for more details."
+            )
 
         x509_crl = self._ffi.gc(x509_crl, self._lib.X509_CRL_free)
         return _CertificateRevocationList(self, x509_crl)
@@ -1185,7 +1191,10 @@ def load_pem_x509_csr(self, data):
         )
         if x509_req == self._ffi.NULL:
             self._consume_errors()
-            raise ValueError("Unable to load request")
+            raise ValueError(
+                "Unable to load request. See https://cryptography.io/en/la"
+                "test/faq/#why-can-t-i-import-my-pem-file for more details."
+            )
 
         x509_req = self._ffi.gc(x509_req, self._lib.X509_REQ_free)
         return _CertificateSigningRequest(self, x509_req)


Test patch:
Repository: pyca/cryptography

Issue:
.from_public_bytes() with incorrect public key size raises cryptography.exceptions.InternalError
**Steps to reproduce**

On Ubuntu 18.10 that comes with OpenSSL 1.1.1, I installed Cryptography 2.4.1 with

    $ python3.6 -m pip install cryptography

I then ran

    >>> from cryptography.hazmat.primitives.asymmetric.x25519 import X25519PublicKey
    >>> X25519PublicKey.from_public_bytes(32*b'a')  # works
    >>> X25519PublicKey.from_public_bytes(31*b'a')  # raises the exception

Also, I installed https://github.com/pyca/cryptography/pull/4580 with

    $ python3.6 -m pip install git+https://github.com/reaperhulk/cryptography.git@x448-support

And with that

    from cryptography.hazmat.primitives.asymmetric.x448 import X448PublicKey
    X448PublicKey.from_public_bytes(56*b'a')  # works
    X448PublicKey.from_public_bytes(55*b'a')  # raises the same exception




Discussion:

Resolving patch:
diff --git a/src/cryptography/hazmat/primitives/asymmetric/x25519.py b/src/cryptography/hazmat/primitives/asymmetric/x25519.py
--- a/src/cryptography/hazmat/primitives/asymmetric/x25519.py
+++ b/src/cryptography/hazmat/primitives/asymmetric/x25519.py
@@ -21,6 +21,10 @@ def from_public_bytes(cls, data):
                 "X25519 is not supported by this version of OpenSSL.",
                 _Reasons.UNSUPPORTED_EXCHANGE_ALGORITHM
             )
+
+        if len(data) != 32:
+            raise ValueError("An X25519 public key is 32 bytes long")
+
         return backend.x25519_load_public_bytes(data)
 
     @abc.abstractmethod


Test patch:
diff --git a/tests/hazmat/primitives/test_x25519.py b/tests/hazmat/primitives/test_x25519.py
--- a/tests/hazmat/primitives/test_x25519.py
+++ b/tests/hazmat/primitives/test_x25519.py
@@ -135,3 +135,10 @@ def test_invalid_type_exchange(self, backend):
         key = X25519PrivateKey.generate()
         with pytest.raises(TypeError):
             key.exchange(object())
+
+    def test_invalid_length_from_public_bytes(self, backend):
+        with pytest.raises(ValueError):
+            X25519PublicKey.from_public_bytes(b"a" * 31)
+
+        with pytest.raises(ValueError):
+            X25519PublicKey.from_public_bytes(b"a" * 33)
Repository: pyca/cryptography

Issue:
Building against openssl-1.1.1 configured with no-psk results broken .so
If openssl 1.1.1 is detected, the TLSv1.3 psk stuff is enabled unconditionally. However, it can be disabled via `no-psk` configuration.

Building against such openssl will give the following:
```
$ ldd /usr/lib/python3.6/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so
	ldd (0x7ff279843000)
	libssl.so.1.1 => /lib/libssl.so.1.1 (0x7ff279705000)
	libcrypto.so.1.1 => /lib/libcrypto.so.1.1 (0x7ff279488000)
	libpython3.6m.so.1.0 => /usr/lib/libpython3.6m.so.1.0 (0x7ff279202000)
	libc.musl-x86_64.so.1 => ldd (0x7ff279843000)
Error relocating /usr/lib/python3.6/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so: SSL_CTX_set_psk_client_callback: symbol not found
Error relocating /usr/lib/python3.6/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so: SSL_CTX_use_psk_identity_hint: symbol not found
Error relocating /usr/lib/python3.6/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so: SSL_CTX_set_psk_server_callback: symbol not found
```


Discussion:
Can you look in opensslconf and tell me what the define is for this? It's probably OPENSSL_NO_PSK but if you could confirm we can add a conditional around this.
Are there distros considering shipping with no-psk enabled btw? We don't support the combinatorial set of all possible OpenSSL configurations as a general policy because testing all of them in CI is effectively impossible. So for a no-psk config we'd want to have a distribution that has chosen to do that before we supported it.
Yes, it is `OPENSSL_NO_PSK`. Currently Alpine Linux ships with that, but I just raised the question if we want to reconsider. See https://github.com/alpinelinux/aports/commit/abe1dc5988d12f5aca771605b109390f33ce7519#commitcomment-31279291
OpenWrt's build system allows disabling PSK support.
Okay, I'm convinced we should support this config. I'll put up a PR for this soon-ish.

Resolving patch:
diff --git a/src/_cffi_src/openssl/ssl.py b/src/_cffi_src/openssl/ssl.py
--- a/src/_cffi_src/openssl/ssl.py
+++ b/src/_cffi_src/openssl/ssl.py
@@ -756,7 +756,7 @@
 static const long Cryptography_HAS_SIGALGS = 1;
 #endif
 
-#if CRYPTOGRAPHY_IS_LIBRESSL
+#if CRYPTOGRAPHY_IS_LIBRESSL || defined(OPENSSL_NO_PSK)
 static const long Cryptography_HAS_PSK = 0;
 int (*SSL_CTX_use_psk_identity_hint)(SSL_CTX *, const char *) = NULL;
 void (*SSL_CTX_set_psk_server_callback)(SSL_CTX *,


Test patch: