On 9/2/21 12:43 PM, Peter Robinson wrote:
On Thu, Sep 2, 2021 at 3:38 PM Tom Rini <tr...@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 <tr...@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...@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?

[1] https://www.openssl.org/news/secadv/20210824.txt

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.

https://www.openssl.org/blog/blog/2018/09/11/release111/

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.

Alex

Reply via email to