The Wayback Machine - https://web.archive.org/web/20220630072811/https://github.com/python/cpython/issues/92876
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hashlib should probably load "default" OpenSSL provider on OpenSSL 3.x explicitly #92876

Open
mgorny opened this issue May 17, 2022 · 0 comments
Open
Labels
expert-SSL type-bug

Comments

@mgorny
Copy link
Contributor

@mgorny mgorny commented May 17, 2022

Bug report

FWIU OpenSSL 3.x disables loading the default provider automatically if one loads a provider explicitly before calling any MD-related function. Since hashlib normally relies on the MDs provided by the default OpenSSL provider, perhaps it should load them explicitly to ensure that they are present. This would also ensure that the loaded OpenSSL providers are consistent whether hashlib is loaded prior to the script loading other providers or not.

By default:

>>> import hashlib
>>> sorted(hashlib.algorithms_available)
['blake2b', 'blake2s', 'md5', 'md5-sha1', 'sha1', 'sha224', 'sha256', 'sha384', 'sha3_224', 'sha3_256', 'sha3_384', 'sha3_512', 'sha512', 'sha512_224', 'sha512_256', 'shake_128', 'shake_256', 'sm3']
>>> hashlib.new("sha512_256")
<sha512_256 _hashlib.HASH object @ 0x7fcccbff2c50>

But if I load the legacy provider first:

>>> import ctypes
>>> ctypes.CDLL("libssl.so").OSSL_PROVIDER_load(None, b"legacy")
-1589238480
>>> import hashlib
>>> sorted(hashlib.algorithms_available)
['blake2b', 'blake2s', 'md4', 'md5', 'mdc2', 'ripemd160', 'sha1', 'sha224', 'sha256', 'sha384', 'sha3_224', 'sha3_256', 'sha3_384', 'sha3_512', 'sha512', 'shake_128', 'shake_256', 'whirlpool']
>>> hashlib.new("sha512_256")
Traceback (most recent call last):
  File "/usr/lib/python3.11/hashlib.py", line 160, in __hash_new
    return _hashlib.new(name, data, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ValueError: [digital envelope routines] unsupported

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.11/hashlib.py", line 166, in __hash_new
    return __get_builtin_constructor(name)(data)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/hashlib.py", line 123, in __get_builtin_constructor
    raise ValueError('unsupported hash type ' + name)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ValueError: unsupported hash type sha512_256
>>> import _hashlib
>>> _hashlib.openssl_md_meth_names
frozenset({'whirlpool', 'ripemd160', 'mdc2', 'md4'})

but if I load both default and legacy providers, I get the full set:

>>> import ctypes
>>> ctypes.CDLL("libssl.so").OSSL_PROVIDER_load(None, b"legacy")
-265107616
>>> ctypes.CDLL("libssl.so").OSSL_PROVIDER_load(None, b"default")
-265087936
>>> import hashlib
>>> sorted(hashlib.algorithms_available)
['blake2b', 'blake2s', 'md4', 'md5', 'md5-sha1', 'mdc2', 'ripemd160', 'sha1', 'sha224', 'sha256', 'sha384', 'sha3_224', 'sha3_256', 'sha3_384', 'sha3_512', 'sha512', 'sha512_224', 'sha512_256', 'shake_128', 'shake_256', 'sm3', 'whirlpool']
>>> hashlib.new("sha512_256")
<sha512_256 _hashlib.HASH object @ 0x7ffb1937f6b0>
>>> import _hashlib
>>> _hashlib.openssl_md_meth_names
frozenset({'sha512_256', 'sha3_512', 'sm3', 'sha512_224', 'sha1', 'md5', 'mdc2', 'sha3_256', 'blake2s', 'ripemd160', 'sha3_224', 'sha256', 'whirlpool', 'sha3_384', 'sha384', 'sha224', 'sha512', 'shake_256', 'md5-sha1', 'blake2b', 'md4', 'shake_128'})

Your environment

  • CPython versions tested on: 3.11.0b1
  • Operating system and architecture: Gentoo Linux amd64
  • OpenSSL version: 3.0.3
@mgorny mgorny added the type-bug label May 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
expert-SSL type-bug
Projects
Status: Todo
Development

No branches or pull requests

2 participants