Intel RDRAND engine [rdrand]
Dynamic engine loading support [dynamic]
2.5.8 (jammy-proposed):
$ sudo openvpn --show-engines
Sorry, OpenSSL hardware crypto engine functionality is not available.
There is a new configure option that could be used to re-enable engines it seems:
--with-openssl-engine enable engine support with OpenSSL. Default enabled for OpenSSL < 3.0, auto,yes,no [default=auto]
We are not using it in our d/rules, so the default takes place which disables engines.
Now, AFAIK engines are indeed deprecated (disabled?) in openssl 3, and enabling them again with the option above might be an error.
Furthermore, I'm not sure if engines in 2.5.5 with openssl 3 are even working. We had a similar case with a squid SRU[1], where using engines with openssl 3 was an error, and later was made more explicit that it was disabled.
So I guess the way forward here is to check whether openvpn 2.5.5 (jammy-updates) could be using openssl 3 engines, correctly. If not, then this aspect of the SRU would not introduce a regression per se. If, however, engines were available and usable there, then we have to evaluate pros and cons of disabling it as upstream wants, or enabling it via --with-openssl-engine and test that it keeps working.
There are other items from the release notes that I wanted to check, but since I stumbled on the above one first, I didn't yet. They are, from 2.5.7:
- "fix client-pending-auth error msg to say ERROR instead of SUCCESS". I assume it's just a string change, and not an actual exit status.
- "Translate openssl 3 digest names to openssl 1.1 ones". Would this impact algorithm names used in configuration files and command-line options?
I went over the changes in openvpn since 2.5.5 all the way to 2.5.9, and I have concerns over this one in particular, in 2.5.7:
The OpenSSL engine feature ``--engine`` is not enabled by default
anymore if OpenSSL 3.0 is detected.
And a quick runtime check of 2.5.5 and 2.5.8 (which we have in jammy-proposed at the moment), shows:
2.5.5 (jammy-updates):
$ sudo openvpn --show-engines
OpenSSL Crypto Engines
Intel RDRAND engine [rdrand]
Dynamic engine loading support [dynamic]
2.5.8 (jammy-proposed):
$ sudo openvpn --show-engines
Sorry, OpenSSL hardware crypto engine functionality is not available.
There is a new configure option that could be used to re-enable engines it seems:
--with- openssl- engine enable engine support with OpenSSL. Default enabled
for OpenSSL < 3.0, auto,yes,no [default=auto]
We are not using it in our d/rules, so the default takes place which disables engines.
Now, AFAIK engines are indeed deprecated (disabled?) in openssl 3, and enabling them again with the option above might be an error.
Furthermore, I'm not sure if engines in 2.5.5 with openssl 3 are even working. We had a similar case with a squid SRU[1], where using engines with openssl 3 was an error, and later was made more explicit that it was disabled.
So I guess the way forward here is to check whether openvpn 2.5.5 (jammy-updates) could be using openssl 3 engines, correctly. If not, then this aspect of the SRU would not introduce a regression per se. If, however, engines were available and usable there, then we have to evaluate pros and cons of disabling it as upstream wants, or enabling it via --with- openssl- engine and test that it keeps working.
There are other items from the release notes that I wanted to check, but since I stumbled on the above one first, I didn't yet. They are, from 2.5.7:
- "fix client-pending-auth error msg to say ERROR instead of SUCCESS". I assume it's just a string change, and not an actual exit status.
- "Translate openssl 3 digest names to openssl 1.1 ones". Would this impact algorithm names used in configuration files and command-line options?
1. https:/ /launchpad. net/ubuntu/ +source/ squid/5. 7-0ubuntu0. 22.04.1