openssl3: ripemd160 not supported

[cculianu (Calin Culianu)]

I'm on Big Sur.

Python 3.6, 3.7, 3.8, and 3.9 can't use the hashlib hasher "ripemd160", even though that hasher is listed as "available".

See below:

$ python3
Python 3.10.0 (default, Nov  7 2021, 21:08:03) [Clang 12.0.5 (clang-1205.0.22.11)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import hashlib
>>> hashlib.algorithms_available
{'sha512_224', 'ripemd160', 'md5-sha1', 'sha1', 'shake_128', 'shake_256', 'sha512_256', 'sha256', 'whirlpool', 'blake2b', 'sha3_512', 'sha384', 'sm3', 'blake2s', 'sha3_224', 'sha224', 'mdc2', 'md4', 'md5', 'sha3_256', 'sha3_384', 'sha512'}
>>> hashlib.new('ripemd160')
Traceback (most recent call last):
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/hashlib.py", line 160, in __hash_new
    return _hashlib.new(name, data, **kwargs)
ValueError: [digital envelope routines] initialization error

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/hashlib.py", line 166, in __hash_new
    return __get_builtin_constructor(name)(data)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/hashlib.py", line 123, in __get_builtin_constructor
    raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type ripemd160

I suspect this new problem has to do with the new OpenSSL3.0. Can we please revert back to 1.1? It seems 3 has caused a bunch of problems already (see my other ticket related to tor not building).

I had to manually modify my /opt/local/var/ macports stuff to force macports to use openssl1.1, and then I told it to reinstall Python3.9 with the -s options (rebuild from source), and now that works.

The problem is most definitely related to openssl 3.0 !!! Please fix!

[jmroot (Joshua Root)]

Seems to be disabled in openssl.

% openssl list -digest-commands
blake2b512        blake2s256        md5               sha1              
sha224            sha256            sha3-224          sha3-256          
sha3-384          sha3-512          sha384            sha512            
sha512-224        sha512-256        shake128          shake256          
sm3

[cculianu (Calin Culianu)]

Ah. So it may be as simple as enabling that at build-time...?

[kencu (Ken)]

the ancient ripemd160 cipher is deprecated in openssl3.

This says it can be exposed by setting an appropriate OPENSSL_API_COMPAT value:

​https://www.openssl.org/docs/man3.0/man7/openssl_user_macros.html

​https://www.openssl.org/docs/man3.0/man3/RIPEMD160.html

​https://www.openssl.org/docs/man3.0/man7/OSSL_PROVIDER-legacy.html

but they really don't want you to use it in openssl 3, as it's not secure, so they make it suitably difficult for you.

[reneeotten (Renee Otten)]

this is considered a ​legacy algorithm so you should probably just use a newer one instead; not sure we want to enable them by default.

[cjones051073 (Chris Jones)]

Indeed, we should not re-enable it.

And no, we will not be reverting to openssl 1.1 but fixes any issues openssl 3 has exposed.

In this case it height be enough to rebuild the py hashlib modules.

[cculianu (Calin Culianu)]

Please re-enable it. Lots of code out there depends on it. It's used in Bitcoin as the hasher for converting public keys -> bitcoin addresses. All bitcoin addresses you have ever seen are generated with that hash.

Which is what I'm using it for -- bitcoin stuff.

It's not insecure per-se due to any flaw in the algorithm. It's just a short hash (160 bits), which these days people consider less than ideal -- but it does NOT have any security flaws.

Bitcoin uses it, it's fine.

There is a ton of other code out there built on top of Python -> openssl that uses it.

If you disable it, it will lead to a bad time for everybody. You will get lots of unhappy users. I guarantee this.

Even if it's deprecated and discouraged it should be available.

Thank you.

[cculianu (Calin Culianu)]

Also on a practical note -- apparently Python still thinks the hasher exists even when re-built against the latest openssl3 from MacPorts.

So practically speaking enabling it will be the shortest route to not having Python erroneously believe it has the algorithm (see my comment above where it's in hashlib.algorithms_available)... only to have it fail when you try to use it!

Not that this is a strong argument in and of itself -- but like I said in my previous comment: I do think not re-enabling this hasher will lead to a lot of unhappiness: there is guaranteed to be a ton of code out there that depends on it. It's always been there -- since OpenSSL 0.9. Having it disappear is guaranteed breakage for tons of software out there....

I humbly ask again: Please reconsider this position.

[mouse07410 (Mouse)]

From cryptography point of view, I support enabling RIPEMD160.

Please reconsider.

[cculianu (Calin Culianu)]

Last message in my 3-message series:

• At the very least offer some variant flag to openssl 3.0 to enable it... so that users that depend on it have some path forward other than building openssl3 themselves.. or uninstalling macports altogether and switching to brew.

[mascguy (Christopher Nielsen)]

If this is breaking downstream components, and it's necessary for backward-compatibility, then we should enable it.

[kencu (Ken)]

what are you asking for exactly?

It is still available in openssl 3 I believe, but you have to go through steps to use it, as it is not available by default.

There is nothing to enable, AFAIK.

[cculianu (Calin Culianu)]

Oh -- so it's there in the lib but downstream components need to enable a #define to see it, huh? I guess Python for example, when it builds, needs to do a dance to see it? Or?

Well if there's nothing that can be done with openssl3 itself for it to "just work" -- then I guess downstream software will become more OpenSSL3 "aware" and fix itself to work right with ripemd160?

Reading the docs it's mysterious to me why python sees it but then it doesn't work anyway, ha ha. May just be an issue with Python...

Yeah, if there's nothing for you to do with the openssl3 package itself, to increase compat... then you can disregard my little rant, I suppose.. :)

[cjones051073 (Chris Jones)]

Just to note to everyone suggesting 'enabling rmd160' by default. If you know how to do this please free to submit a PR doing it.....Just asking someone else to do it does not help.

Looking at the openssl configuration myself I don't know how it is done, or even if it can be easily at build time for openssl.

[cculianu (Calin Culianu)]

Yeah, I have no idea how to do it. Note that this may just be an issue in upstream Python -- the rabbit hole starts here:

​https://github.com/python/cpython/pull/19878

So maybe when Python gets its ducks in a row, it will "just work as before" with OpenSSL 3.0 and all hashlibs will be available...

[cjones051073 (Chris Jones)]

This does to me look more like an issue with python that it does openssl3…

[mouse07410 (Mouse)]

First, no offense meant, but the current OpenSSL-3 port seems screwed. Here's one illustration, showing RIPEMD issue:

$ openssl version
OpenSSL 3.0.0 7 sep 2021 (Library: OpenSSL 3.0.0 7 sep 2021)
$ openssl speed ripemd160 sha256
Doing sha256 for 3s on 16 size blocks: 7626940 sha256's in 3.00s
Doing sha256 for 3s on 64 size blocks: 5517678 sha256's in 2.99s
Doing sha256 for 3s on 256 size blocks: 3297906 sha256's in 3.01s
Doing sha256 for 3s on 1024 size blocks: 1233593 sha256's in 3.00s
Doing sha256 for 3s on 8192 size blocks: 180307 sha256's in 3.00s
Doing sha256 for 3s on 16384 size blocks: 91294 sha256's in 3.00s
Doing rmd160 for 3s on 16 size blocks: rmd160 error!
002E4C0201000000:error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported:crypto/evp/evp_fetch.c:346:Global default library context, Algorithm (RIPEMD160 : 101), Properties ()
002E4C0201000000:error:03000086:digital envelope routines:evp_md_init_internal:initialization error:crypto/evp/digest.c:234:
version: 3.0.0
built on: built on: Thu Oct 14 00:15:47 2021 UTC
options:bn(64,64) 
compiler: /usr/bin/clang -fPIC -arch x86_64 -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk -arch x86_64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk -DL_ENDIAN -DOPENSSL_PIC -D_REENTRANT -DOPENSSL_BUILDING_OPENSSL -DZLIB -DNDEBUG -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk
CPUINFO: OPENSSL_ia32cap=0x7ffef3ffffebffff:0x139efffb
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
rmd160               0.00         0.00         0.00         0.00         0.00         0.00 
sha256           40677.01k   118104.14k   280486.36k   421066.41k   492358.31k   498586.97k

If RIPEMD is present, I'd expect some reasonable numbers. If it is not - I'd expect an error message.

Also, this does not seem right:

$ openssl engine -t
(rdrand) Intel RDRAND engine
     [ available ]
(dynamic) Dynamic engine loading support
     [ unavailable ]

Very few of crypto engines (like, PKCS#11 engine) successfully moved to the new Provider interface (which, BTW, still has problems). So, configuring OpenSSL-3 without them does not make sense at all.

[cjones051073 (Chris Jones)]

Replying to mouse07410:

First, no offense meant, but the current OpenSSL-3 port seems screwed. Here's one illustration, showing RIPEMD issue:

$ openssl version
OpenSSL 3.0.0 7 sep 2021 (Library: OpenSSL 3.0.0 7 sep 2021)
$ openssl speed ripemd160 sha256
Doing sha256 for 3s on 16 size blocks: 7626940 sha256's in 3.00s
Doing sha256 for 3s on 64 size blocks: 5517678 sha256's in 2.99s
Doing sha256 for 3s on 256 size blocks: 3297906 sha256's in 3.01s
Doing sha256 for 3s on 1024 size blocks: 1233593 sha256's in 3.00s
Doing sha256 for 3s on 8192 size blocks: 180307 sha256's in 3.00s
Doing sha256 for 3s on 16384 size blocks: 91294 sha256's in 3.00s
Doing rmd160 for 3s on 16 size blocks: rmd160 error!
002E4C0201000000:error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported:crypto/evp/evp_fetch.c:346:Global default library context, Algorithm (RIPEMD160 : 101), Properties ()
002E4C0201000000:error:03000086:digital envelope routines:evp_md_init_internal:initialization error:crypto/evp/digest.c:234:
version: 3.0.0
built on: built on: Thu Oct 14 00:15:47 2021 UTC
options:bn(64,64) 
compiler: /usr/bin/clang -fPIC -arch x86_64 -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk -arch x86_64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk -DL_ENDIAN -DOPENSSL_PIC -D_REENTRANT -DOPENSSL_BUILDING_OPENSSL -DZLIB -DNDEBUG -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk
CPUINFO: OPENSSL_ia32cap=0x7ffef3ffffebffff:0x139efffb
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
rmd160               0.00         0.00         0.00         0.00         0.00         0.00 
sha256           40677.01k   118104.14k   280486.36k   421066.41k   492358.31k   498586.97k

If RIPEMD is present, I'd expect some reasonable numbers. If it is not - I'd expect an error message.

I see an error message above. Maybe not worded how you would prefer, but its there.

Also, this does not seem right:

$ openssl engine -t
(rdrand) Intel RDRAND engine
     [ available ]
(dynamic) Dynamic engine loading support
     [ unavailable ]

Very few of crypto engines (like, PKCS#11 engine) successfully moved to the new Provider interface (which, BTW, still has problems). So, configuring OpenSSL-3 without them does not make sense at all.

I am not sure exactly what point you are making here, but again, if you have a specific suggestion to make on how to configure openssl3 (which is essentially just using the upstream defaults) please open a PR implementing your suggestion.

[cculianu (Calin Culianu)]

Jesus. openssl can't even talk to openssl?!? LOL. The OpenSSL team made a real quality release there.. kudos to the OpenSSL guys.

Just kidding.. snarkyness aside -- it looks like this is just a transition period, as is to be expected. I sincerely hope that either a) some magical build flags save everything or that b) every downstream project gets its ducks in a row eventually.

Still though, pretty funny that even openssl can't speak to openssl.. ha ha ha :)

[mouse07410 (Mouse)]

Just to note to everyone suggesting 'enabling rmd160' by default. If you know how to do this please free to submit a PR doing it.....Just asking someone else to do it does not help.

In the configuration, you need to add enable-rmd160 flag. Here's what my config looks like:

./config --prefix=${OPENSSL_DIR} --debug --openssldir=${OPENSSL_DIR}/etc --with-rand-seed=rdcpu,os enable-ec_nistp_64_gcc_128 enable-md2 enable-rc5 enable-rmd160 enable-weak-ssl-ciphers zlib-dynamic enable-ssl-trace enable-trace threads enable-buildtest-c++

You don't have to enable everything that I did (though I assure you it is OK if you know what you're doing ;).

Sorry, I don't know how to do PRs on Macports. But knowing what flag to add, it should be a no-brainer for somebody who's maintaining it already.

[cjones051073 (Chris Jones)]

Mouse, did you actually test to see if it had helped, adding 'enable-rmd160' to the configure args ? As I had already tried that and it didn't change anything.

i.e. with

Executing:  cd "/opt/local/var/macports/build/_Users_chris_Projects_MacPorts_ports_devel_openssl3/openssl3/work/openssl-3.0.0" && ./Configure --prefix=/opt/local/libexec/openssl3 -L/opt/local/lib --openssldir=/opt/local/libexec/openssl3/etc/openssl enable-rmd160 shared zlib '-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk' -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk darwin64-x86_64-cc 

I still get errors like

Oberon ~/Projects/MacPorts/ports > openssl speed ripemd160 sha256
Doing sha256 for 3s on 16 size blocks: 6509762 sha256's in 2.98s
Doing sha256 for 3s on 64 size blocks: 4573714 sha256's in 2.98s
Doing sha256 for 3s on 256 size blocks: 2663228 sha256's in 2.98s
Doing sha256 for 3s on 1024 size blocks: 978493 sha256's in 2.98s
Doing sha256 for 3s on 8192 size blocks: 141694 sha256's in 2.98s
Doing sha256 for 3s on 16384 size blocks: 72142 sha256's in 2.98s
Doing rmd160 for 3s on 16 size blocks: rmd160 error!

[cjones051073 (Chris Jones)]

Same with the full set of flags you used, still does not work

Executing:  cd "/opt/local/var/macports/build/_Users_chris_Projects_MacPorts_ports_devel_openssl3/openssl3/work/openssl-3.0.0" && ./Configure --prefix=/opt/local/libexec/openssl3 -L/opt/local/lib --openssldir=/opt/local/libexec/openssl3/etc/openssl --with-rand-seed=rdcpu,os enable-ec_nistp_64_gcc_128 enable-md2 enable-rc5 enable-rmd160 enable-weak-ssl-ciphers zlib-dynamic enable-ssl-trace enable-trace threads enable-buildtest-c++ '-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk' -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk darwin64-x86_64-cc 
Configuring OpenSSL version 3.0.0 for target darwin64-x86_64-cc
Creating configdata.pm
Running configdata.pm
Creating Makefile.in
Creating Makefile

**********************************************************************
***                                                                ***
***   OpenSSL has been successfully configured                     ***
***                                                                ***
***   If you encounter a problem while building, please open an    ***
***   issue on GitHub <https://github.com/openssl/openssl/issues>  ***
***   and include the output from the following command:           ***
***                                                                ***
***       perl configdata.pm --dump                                ***
***                                                                ***
***   (If you are new to OpenSSL, you might want to consult the    ***
***   'Troubleshooting' section in the INSTALL.md file first)      ***
***                                                                ***
**********************************************************************

also gives

Oberon ~/Projects/MacPorts/ports > openssl speed rmd160        
Doing rmd160 for 3s on 16 size blocks: rmd160 error!
00F66D0B01000000:error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported:crypto/evp/evp_fetch.c:346:Global default library context, Algorithm (RIPEMD160 : 103), Properties ()
00F66D0B01000000:error:03000086:digital envelope routines:evp_md_init_internal:initialization error:crypto/evp/digest.c:234:
version: 3.0.0
built on: built on: Mon Nov  8 22:01:52 2021 UTC
options:bn(64,64) 
compiler: /usr/bin/clang -fPIC -arch x86_64 -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk -arch x86_64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk -DL_ENDIAN -DOPENSSL_PIC -D_REENTRANT -DOPENSSL_BUILDING_OPENSSL -DZLIB -DZLIB_SHARED -DNDEBUG -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk
CPUINFO: OPENSSL_ia32cap=0x7ffaf3bfffebffff:0x27ab
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
rmd160               0.00         0.00         0.00         0.00         0.00         0.00 

[mouse07410 (Mouse)]

Mouse, did you actually test to see if it had helped, adding 'enable-rmd160' to the configure args ? As I had already tried that and it didn't change anything.

Before leaving the machine running build, I tested that that's the option for enabling RIPEMD160 that does not blow the config. Because, e.g., enable-ripemd160 makes the config barf...

That option gets accepted by the configurator, and OpenSSL-3.1.0-dev gets built successfully. And passes all the tests.

Now, the "pleasant" part: I concur - the darn thing just doesn't work! (Note: I work with master - but the results here are the same as yours.)

$ openssl3 speed ripemd160
Doing rmd160 for 3s on 16 size blocks: rmd160 error!
005EB70F01000000:error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported:crypto/evp/evp_fetch.c:349:Global default library context, Algorithm (RIPEMD160 : 97), Properties ()
005EB70F01000000:error:03000086:digital envelope routines:evp_md_init_internal:initialization error:crypto/evp/digest.c:235:
version: 3.1.0-dev
built on: Mon Nov  8 22:40:20 2021 UTC
options: bn(64,64)
compiler: clang -fPIC -arch x86_64 -O3 -std=gnu18 -march=native -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -g -DL_ENDIAN -DOPENSSL_PIC -D_REENTRANT -DOPENSSL_BUILDING_OPENSSL -DZLIB -DZLIB_SHARED
CPUINFO: OPENSSL_ia32cap=0x7ffaf3bfffebffff:0x40000008029c67af
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
rmd160               0.00         0.00         0.00         0.00         0.00         0.00 
$ openssl3 speed rmd160
Doing rmd160 for 3s on 16 size blocks: rmd160 error!
005EA61201000000:error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported:crypto/evp/evp_fetch.c:349:Global default library context, Algorithm (RIPEMD160 : 97), Properties ()
005EA61201000000:error:03000086:digital envelope routines:evp_md_init_internal:initialization error:crypto/evp/digest.c:235:
version: 3.1.0-dev
built on: Mon Nov  8 22:40:20 2021 UTC
options: bn(64,64)
compiler: clang -fPIC -arch x86_64 -O3 -std=gnu18 -march=native -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -g -DL_ENDIAN -DOPENSSL_PIC -D_REENTRANT -DOPENSSL_BUILDING_OPENSSL -DZLIB -DZLIB_SHARED
CPUINFO: OPENSSL_ia32cap=0x7ffaf3bfffebffff:0x40000008029c67af
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
rmd160               0.00         0.00         0.00         0.00         0.00         0.00 
$

So, the flag enable-rmd160 must be present - however, it's "necessary but insufficient". :-(

I filed the issue upstream: ​https://github.com/openssl/openssl/issues/16994

And, adding -provider legacy to the command line invocation, I see some improvements:

$ openssl3 speed -provider legacy rmd160
Doing rmd160 for 3s on 16 size blocks: 7105946 rmd160's in 3.00s
Doing rmd160 for 3s on 64 size blocks: 5105109 rmd160's in 2.99s
Doing rmd160 for 3s on 256 size blocks: 2798150 rmd160's in 3.00s
Doing rmd160 for 3s on 1024 size blocks: 998097 rmd160's in 3.00s
Doing rmd160 for 3s on 8192 size blocks: 131755 rmd160's in 2.96s
Doing rmd160 for 3s on 16384 size blocks: 70219 rmd160's in 2.99s
00BE861101000000:error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported:crypto/evp/evp_fetch.c:349:Global default library context, Algorithm (CTR-DRBG : 0), Properties (<null>)
00BE861101000000:error:12000090:random number generator:rand_new_drbg:unable to fetch drbg:crypto/rand/rand_lib.c:567:
$ 

[mouse07410 (Mouse)]

OK, following the guidance received upstream, to use RIPEMD160 (and other algorithms form the legacy provider), one needs to modify openssl.cnf along these lines:

openssl_conf = openssl_init

[openssl_init]
providers = provider_sect

[provider_sect]
default = default_sect
legacy = legacy_sect

[default_sect]
activate = 1

[legacy_sect]
activate = 1

After doing that, I see

$ openssl3 speed ripemd160
Doing rmd160 for 3s on 16 size blocks: 6766057 rmd160's in 3.00s
Doing rmd160 for 3s on 64 size blocks: 4862997 rmd160's in 2.99s
Doing rmd160 for 3s on 256 size blocks: 2684597 rmd160's in 3.00s
Doing rmd160 for 3s on 1024 size blocks: 953442 rmd160's in 2.99s
Doing rmd160 for 3s on 8192 size blocks: 137347 rmd160's in 3.00s
Doing rmd160 for 3s on 16384 size blocks: 69022 rmd160's in 2.99s
version: 3.1.0-dev
built on: Mon Nov  8 22:40:20 2021 UTC
options: bn(64,64)
compiler: clang -fPIC -arch x86_64 -O3 -std=gnu18 -march=native -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -g -DL_ENDIAN -DOPENSSL_PIC -D_REENTRANT -DOPENSSL_BUILDING_OPENSSL -DZLIB -DZLIB_SHARED
CPUINFO: OPENSSL_ia32cap=0x7ffaf3bfffebffff:0x40000008029c67af
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
rmd160           36085.64k   104090.91k   229085.61k   326529.97k   375048.87k   378212.86k
$ 

This is with OpenSSL-3.1.0-dev that I'm tracking locally, but I'm sure it will be the same with 3.0.0.

Update: I've just tested modifying config for the Macports OpenSSL-3.0.0. It seems to work as expected.

[cjones051073 (Chris Jones)]

right, this looks like something that can be done automatically in the port I guess....

[mouse07410 (Mouse)]

this looks like something that can be done automatically in the port I guess....

I would probably do it...

[jmroot (Joshua Root)]

In 259e6a39c42a067553734bb80f62bd2a4513f88f/macports-ports (master):

python*: switch back to openssl 1.1

Upstream support for 3 isn't done yet.

See: #63857

[cjones051073 (Chris Jones)]

see ​https://github.com/macports/macports-ports/commit/df5e1c619a6d1884ccf234d4e652d2303af09e35

with that I get

Oberon ~/Projects/MacPorts/ports > openssl-3  speed rmd160                 
Doing rmd160 for 3s on 16 size blocks: 6942915 rmd160's in 3.00s
Doing rmd160 for 3s on 64 size blocks: 4951632 rmd160's in 2.99s
Doing rmd160 for 3s on 256 size blocks: 2642806 rmd160's in 2.99s
Doing rmd160 for 3s on 1024 size blocks: 955875 rmd160's in 2.99s
Doing rmd160 for 3s on 8192 size blocks: 136657 rmd160's in 2.99s
Doing rmd160 for 3s on 16384 size blocks: 69520 rmd160's in 2.99s
version: 3.0.0
built on: built on: Tue Nov  9 01:29:21 2021 UTC
options:bn(64,64) 
compiler: /usr/bin/clang -fPIC -arch x86_64 -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk -arch x86_64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk -DL_ENDIAN -DOPENSSL_PIC -D_REENTRANT -DOPENSSL_BUILDING_OPENSSL -DZLIB -DNDEBUG -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk
CPUINFO: OPENSSL_ia32cap=0x7ffaf3bfffebffff:0x27ab
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
rmd160           37028.88k   105988.11k   226273.69k   327363.21k   374412.76k   380941.70k

and

Oberon ~/Projects/MacPorts/ports > python3
Python 3.10.0 (default, Nov  7 2021, 13:01:11) [Clang 13.0.0 (clang-1300.0.29.3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import hashlib
>>> hashlib.new('rmd160')
<ripemd160 _hashlib.HASH object @ 0x102850230>
>>> 

note this with with python310 from before Joshua roll back to 1.1....

[cculianu (Calin Culianu)]

Replying to jmroot:

In 259e6a39c42a067553734bb80f62bd2a4513f88f/macports-ports (master):

python*: switch back to openssl 1.1

Upstream support for 3 isn't done yet.

See: #63857

YAY! THANK YOU!

[reneeotten (Renee Otten)]

isn't it bit excessive to revert to openssl11 just for the fact that one legacy algorithm isn't available...? The whole point of switching to openssl3 is to have a more liberal license so that a whole bunch of packages will become distributable. Having all Python ports stuck again with version 1.1 pretty much kills that goal.

[mascguy (Christopher Nielsen)]

Replying to reneeotten:

Isn't it a bit excessive to revert to openssl11 just for the fact that one legacy algorithm isn't available...? The whole point of switching to openssl3 is to have a more liberal license so that a whole bunch of packages will become distributable. Having all Python ports stuck again with version 1.1 pretty much kills that goal.

I initially felt the same way, Renee. Then I did some Googling related to upstream's current status, and it looks like some key things are still not complete. (Or at least, not Production-worthy yet.)

I'll let Josh elaborate more. But as disappointing as it is to revert to OpenSSL 1.1, it seems justifiable in this particular case.

Thoughts?

[cjones051073 (Chris Jones)]

I tend to agree.

Also, interesting to note that the older pythons are likely never going to get (official) patches to support openssl3, so is it then not better to keep them on openssl11 and only migrate the newer releases (3.10, 3.9 ...) once they get support added.

[mouse07410 (Mouse)]

. . . as disappointing as it is to revert to OpenSSL 1.1, it seems justifiable in this particular case. Thoughts?

I see no problem with this downgrading, especially given how different and under-documented OpenSSL 3.x is.

[mascguy (Christopher Nielsen)]

We may be able to switch back to OpenSSL, at least for newer Pythons. But still TBD; see: comment:32:issue:63801

[jmroot (Joshua Root)]

Related: ​https://bugs.python.org/issue47101