On Thu, Sep 02, 2021 at 12:48:29PM -0500, Alex G. wrote:
On 9/2/21 12:43 PM, Peter Robinson wrote:
On Thu, Sep 2, 2021 at 3:38 PM Tom Rini trini@konsulko.com wrote:
On Thu, Sep 02, 2021 at 03:36:43PM +0100, Peter Robinson wrote:
On Thu, Sep 2, 2021 at 2:28 PM Tom Rini trini@konsulko.com wrote:
On Thu, Jul 29, 2021 at 01:31:21PM -0500, Alexandru Gagniuc wrote:
Older OpenSSL and libressl versions have a slightly different API. This require #ifdefs to support. However, we still can't support it because the ECDSA path does not compile with these older versions. These #ifdefs are truly a vestigial appendage.
Alternatively, the ECDSA path could be updated for older libraries, but this requires significant extra code, and #ifdefs. Those libraries are over three years old, and there concerns whether it makes sense to build modern software for real world use against such old libraries.
Thusly, remove #ifdefs and code for old OpenSSL and LibreSSL support.
Signed-off-by: Alexandru Gagniuc mr.nuke.me@gmail.com
Applied to u-boot/next, thanks!
According to recent CVE announcements 1.1.0 is out of support [1], does it make sense to just support 1.1.1x and later?
Good question. Are there API changes between 1.1.0 and 1.1.1x ?
So outside of the new TLS 1.3 feature the release says "What’s more is that OpenSSL 1.1.1 is API and ABI compliant with OpenSSL 1.1.0" and depending on how we use openssl it may even be API compatible with 3.0 when it comes out any time now.
Okay, I don't think it's worth excluding 1.1.0 then. The only way we could do that is a compile time check against OPENSSL_VERSION.
That won't prevent someone from compiling with openssl 1.1.1, and then just replacing libcrypto.so with 1.1.0.
That's what I was figuring. If there was compatibility code we could drop, it would make sense. But since there's not, I don't think we're in a position to really influence things.