I would like to report that the newly added dependency on Rust has made it impossible to package cryptography for a number of supported Gentoo architectures (and these are architectures where people actually use Python packages that depend on cryptography).

Please see Platform Support. Besides degrading a few of our targets to 'Tier 3', Rust completely does not support at least alpha, hppa, ia64, m68k, s390 (not -x). The cost of adjusting cryptography's C code to these platforms (even if we assumed they wouldn't work out of the box as they do so far) is much less than the cost of porting the whole Rust. You can't really expect volunteers to port the whole Rust to other architectures just to get cryptography back.

Right now it's a really hard struggle to even get Rust packaged for non-Tier 1 architectures (i.e. where upstream does not provide bootstrap binaries).

This will allow folks with GPLv2 codebases to use us, and is a blocker for PyCrypto to be implemented on top of us. I've consulted with an IP lawyer to verify that this will allow more people to use Cryptography, while still giving us the protections of the Apache license.

Tasks:

• [x] Update LICENSE file appropriately
• [x] Update setup.py classifiers
• [x] Update __about__.py and cryptography_vectors/__about__.py
• [x] Figure out what to do with copyright headers in every file
• [x] Update contributing documentation
• [x] Receive consent of all folks who have contributed to cryptography in the past.
• [x] Changelog entry.

List of folks whose consent we need:

• [x] Alex Gaynor
• [x] Paul Kehrer
• [x] David Reid
• [x] Alex Stapleton
• [x] Donald Stufft
• [x] Ayrx
• [x] Laurens Van Houtven
• [x] Mohammed Attia
• [x] Jean-Paul Calderone
• [x] cyli
• [x] Hynek Schlawack
• [x] Julian Krause
• [x] Richard Wall
• [x] Ashwini Oruganti
• [x] PhiBo
• [x] Matthew Iversen
• [x] Christian Heimes
• [x] Chris Glass
• [x] Chirag Jog
• [x] Kubilay Kocak
• [x] Konstantinos Koukopoulos
• [x] timic
• [x] ashfall
• [x] Nic Young
• [x] Jeff Tang
• [x] Fedor Brunner
• [x] Daniele Sluijters
• [x] Cory Benfield
• [x] skeuomorf
• [x] Matt Iversen
• [x] Kyle Kelley
• [x] Kimmo Parviainen-Jalanko
• [x] manuels
• [x] kennwhite
• [x] Wouter Bolsterlee
• [x] Thomas Fenzl
• [x] Taewook Kang
• [x] Stephen Holsapple
• [x] Sascha Peilicke
• [x] Marcin Wielgoszewski
• [x] Jonathan Giannuzzi
• [x] Jay Parlar
• [x] D.S. Ljungmark
• [x] Arturo Filastò

This temporarily uses the backend to do it until the alternate approach is ready. DSA/ECDSA and public key support will follow if this is deemed worthy.

OMFG. Not final.

Implements:

• the core "PEM" parser logic
• PEM decryption
• Handling of the ASN.1 DER for ECDSA Private Keys

Not done:

• Parsing of a bunch of other key types
• non-md5 based PBES

Some notes:

• I don't understand the error handling around ASN.1 well enough yet, which makes me pretty uncomfortable given the sensitivity of this stuff.
• PyASN.1's API is kind of miserable, but it does appear to be complete
• There's some not-great error handling in (at least) the EC number loading in the OpenSSL backend
• Bits vs. Bytes for key_size is the worst :-(
• If we're comitted to doing this, it's going to be a decent sized project. We'll have to keep the old key loading logic around and port one key type at a time.
• I don't know if I read the RFC closely enough :-( There's all kinds of random notes in various places, and I assume if I ignore any one of those the security of the system is screwed.

FEEDBACK PLEASE!!! :-)

This is based on @Ivoz branch. Instead of creating a new repo, this just creates a new top level folder with a package hidden inside it.

I've probably done lots of things horribly wrong. I suck at packaging.

With this we end up with 2 sdist packages. One is the actual code at 300KB, the other is all the test vectors at 16MB.

Added the ability to load and perform functions with RSA and DSA public keys when the files contain public keys only. Also added test functions and OpenSSL-generated files to test the new code, which all pass on Windows 7.

This is a proposed solution to our concerns about fork() with regard to the userland CSPRNG OpenSSL uses (currently blocking #292). It adds a new engine named "osrandom" and sets it as the default RAND source when you instantiate a backend object. unregister_osrandom_engine sets it back to the OpenSSL default CSPRNG while register_osrandom_engine reactivates it. These methods exist for users who wish to explicitly opt out of the urandom/cryptgenrandom option.

• [x] *nix support
• [x] win32 support (via CryptGenRandom)
• [x] register/unregister
• [x] documentation regarding linux urandom, BSD/OS X yarrow random, etc

A few notes: On linux/OS X urandom is ~33% slower than the OpenSSL CSPRNG.

$ python -V
Python 3.8.5

$ pip list
Package      Version
------------ -------
cffi         1.14.2
cryptography 3.1
pip          20.2.2
pycparser    2.20
setuptools   49.6.0
six          1.15.0

$ python
Python 3.8.5 (default, Jul 22 2020, 17:45:49)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from cryptography.hazmat.bindings.openssl.binding import Binding as SSLBinding
>>> SSLBinding.lib.PKCS7_sign
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: module 'lib' has no attribute 'PKCS7_sign'
>>>

$ pip install cryptography==3.0
...
Successfully installed cryptography-3.0

$ python
Python 3.8.5 (default, Jul 22 2020, 17:45:49)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from cryptography.hazmat.bindings.openssl.binding import Binding as SSLBinding
>>> SSLBinding.lib.PKCS7_sign
<built-in method PKCS7_sign of _cffi_backend.Lib object at 0x7f501012c630>
>>>

Due to differences in how py.test determines which module to import the test suite actually runs against the cryptography which is in the current directory instead of the cryptography which is installed. The problem essentially boils down to when there is a tests/init.py then py.test adds the current directory to the front of the sys.path, causing it to take precedence over the installed location.

This means that running the tests relies on the implicit compile that CFFI does instead of testing against what people will actually be runnning, which is the module compiled by setup.py.

This should also cause the tests to run a little bit faster as something like tox -e py34 currently compiles everything 3 times instead of only once like it should. This PR will drop this down to 2 times.

Resolves #276

• [x] Documentation
• [x] 3.x hashlib interface
• [x] 2.7 hashlib interface
• [x] 2.6 hashlib interface
• [x] Port PyPy test_hashlib.py to py.test?

Summary Installing cryptography on aarch64 via pip using command "pip3 install cryptography" tries to build wheel from source code

Problem description cryptography don't have wheel for aarch64 on PyPI repository. So, while installing cryptography via pip on aarch64, pip builds wheel for same resulting in it takes more time to install cryptography. Making wheel available for aarch64 will benefit aarch64 users by minimizing cryptography installation time.

Expected Output Pip should be able to download cryptography wheel from PyPI repository rather than building it from source code.

@cryptography-team, please let me know if I can help you building wheel/uploading to PyPI repository. I am curious to make cryptography wheel available for aarch64. It will be a great opportunity for me to work with you.

Hello, I noticed that the size of the package increased from 0.6MB to 13MB between the version 38.0.4 and 39.0.0. Is this intended or is this caused by an issue? I noticed that, because I am using this library in an AWS Lambda function, and the lambda function can only display code with a size of 6 MB. Due to the new sized 'cryptography' package, this is no longer possible.

The cryptography lib is getting installed when I am using the MSAL lib

Any help to improve the size is appreciated.

I'm getting below error after installing latest version of cryptography by using requirements.txt file in AWS deployment.

import OpenSSL.SSL
File "/root/.pyenv/versions/3.9.12/lib/python3.9/site-packages/OpenSSL/__init__.py", line 8, in <module>
from OpenSSL import crypto, SSL
File "/root/.pyenv/versions/3.9.12/lib/python3.9/site-packages/OpenSSL/crypto.py", line 3268, in <module>
_lib.OpenSSL_add_all_algorithms()
**_AttributeError: module 'lib' has no attribute 'OpenSSL_add_all_algorithms'_**

versions used during installation- cryptography-39.0.0 Python- 3.9 cffi--1.15.1 pip-22.3.1 setuptools-58.1.0

Could you please help me in resolving this issue?

Hey there! Tryna run something that is compiled on linux with pyinstaller on another linux system.

Versions:

pip                    22.0.2
cryptography           3.4.8
cffi                   1.15.1
setuptools             59.6.0

Traceback https://cdn.skrrrtt.cool/p/raw/files/2yftsm2koio21kre9

A new vulnerability CVE-2022-3996 has been discovered in OpenSSL, affecting OpenSSL 3.0.0-3.0.7. The OpenSSL used in cryptography is 3.0.7. Is cryptography affected by the openssl CVE-2022-3996 vulnerability?

https://nvd.nist.gov/vuln/detail/CVE-2022-3996