Message ID | 20210914180728.23695-1-cotequeiroz@gmail.com |
---|---|
State | Superseded |
Delegated to: | Petr Štetiar |
Headers | show |
Series | [19.07] wolfssl: update to 4.8.1-stable | expand |
Eneas U de Queiroz <cotequeiroz@gmail.com> [2021-09-14 15:07:28]: Hi Eneas, > Changes from 4.7.0: > Fix one high (OCSP verification issue) and two low vulnerabilities > Improve compatibility layer > Other improvements and fixes I'm wondering if we can do such an upgrade as the binary compatibility report for wolfSSL 4.7.0 vs 4.8.0 looks quite scary to me. Would it be possible to just backport those patches which fixes those security related issues? 1. https://abi-laboratory.pro/index.php?view=compat_report&l=wolfssl&v1=4.7.0&v2=4.8.0&obj=948e4&kind=abi#Removed -- ynezz
On Sun, Dec 12, 2021 at 12:11 PM Petr Štetiar <ynezz@true.cz> wrote: > > I'm wondering if we can do such an upgrade as the binary compatibility report for > wolfSSL 4.7.0 vs 4.8.0 looks quite scary to me. Would it be possible to just > backport those patches which fixes those security related issues? > Most wolfSSL releases have binary compatibility issues. I would not recommend anyone to update just the package, even if the abi-laboratory report was less scary. This illustrates well the problem with binary package updates that jow wants to address. I was not sure if it would be acceptable to do the version update, but then we went from 4.3.0 in 19.07.0 to 4.5.0 in 19.07.4, then 4.6.0 in 19.07.5, and 4.7.0 in 19.07.8, so why not 4.8.1? OpenWrt 19.07 support is officially limited to security maintenance, so we can cherry-pick a couple of wolfssl commits instead: 73076940a Fix CompareOcspReqResp. f93083be7 OCSP: improve handling of OCSP no check extension (excluding tests): src/ssl.c | 2 +- wolfcrypt/src/asn.c | 19 ++++++++++++------- wolfssl/wolfcrypt/asn.h | 1 + 3 files changed, 14 insertions(+), 8 deletions(-) Just let me know what's the best approach here. After this is done--whether update or patch--I intend to propose a patch to build with WOLFSSL_ALT_CERT_CHAINS to avoid the problems with letsencrypt certificates. One can argue that it is a security fix, considering that the alternative is to skip certificate validation. If this is going to be NAKed, then I'll skip the trouble. BTW, wolfssl, 5.0.0 is out, but I've been unable to make it work with the letsencrypt certificates even with the build-option active--there may be other problems that I don't recall now, I haven't looked at it lately. I'll return to it when able. Meanwhile, I'll try to get patches for the security problems that were fixed. Cheers, Eneas
Eneas U de Queiroz <cotequeiroz@gmail.com> [2021-12-14 14:54:44]: Hi, > OpenWrt 19.07 support is officially limited to security maintenance, > so we can cherry-pick a couple of wolfssl commits instead: > 73076940a Fix CompareOcspReqResp. > f93083be7 OCSP: improve handling of OCSP no check extension > > (excluding tests): > src/ssl.c | 2 +- > wolfcrypt/src/asn.c | 19 ++++++++++++------- > wolfssl/wolfcrypt/asn.h | 1 + > 3 files changed, 14 insertions(+), 8 deletions(-) > > Just let me know what's the best approach here. lets see the diff, but it looks like a good proposal to me. > After this is done--whether update or patch--I intend to propose a > patch to build with WOLFSSL_ALT_CERT_CHAINS to avoid the problems with > letsencrypt certificates. One can argue that it is a security fix, > considering that the alternative is to skip certificate validation. > If this is going to be NAKed, then I'll skip the trouble. You mean cherry-picking 28d8e6a8711ba78f1684a205e11b0dbd4ff2b2f3 ? It's really PITA without this as one needs to make server side compatible with those broken clients, so I would be in favor to fixing this. I've just checked the API/ABI compatibility and it should be fine, that flag adds 2 new symbols so this shouldn't cause any harm (tm). -- ynezz
diff --git a/package/libs/wolfssl/Makefile b/package/libs/wolfssl/Makefile index 57fcaa03b2..4940316f1b 100644 --- a/package/libs/wolfssl/Makefile +++ b/package/libs/wolfssl/Makefile @@ -8,12 +8,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=wolfssl -PKG_VERSION:=4.7.0-stable +PKG_VERSION:=4.8.1-stable PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=https://github.com/wolfSSL/wolfssl/archive/v$(PKG_VERSION) -PKG_HASH:=b0e740b31d4d877d540ad50cc539a8873fc41af02bd3091c4357b403f7106e31 +PKG_HASH:=50db45f348f47e00c93dd244c24108220120cb3cc9d01434789229c32937c444 PKG_FIXUP:=libtool PKG_INSTALL:=1 diff --git a/package/libs/wolfssl/patches/100-disable-hardening-check.patch b/package/libs/wolfssl/patches/100-disable-hardening-check.patch index c89ff1be9d..4141e28750 100644 --- a/package/libs/wolfssl/patches/100-disable-hardening-check.patch +++ b/package/libs/wolfssl/patches/100-disable-hardening-check.patch @@ -1,6 +1,6 @@ --- a/wolfssl/wolfcrypt/settings.h +++ b/wolfssl/wolfcrypt/settings.h -@@ -2255,7 +2255,7 @@ extern void uITRON4_free(void *p) ; +@@ -2274,7 +2274,7 @@ extern void uITRON4_free(void *p) ; #endif /* warning for not using harden build options (default with ./configure) */ diff --git a/package/libs/wolfssl/patches/110-build-with-libtool-2.4.patch b/package/libs/wolfssl/patches/110-build-with-libtool-2.4.patch new file mode 100644 index 0000000000..206c6dac6a --- /dev/null +++ b/package/libs/wolfssl/patches/110-build-with-libtool-2.4.patch @@ -0,0 +1,13 @@ +diff --git a/configure.ac b/configure.ac +index 144c857e4..de7f6b45a 100644 +--- a/configure.ac ++++ b/configure.ac +@@ -32,7 +32,7 @@ AC_ARG_PROGRAM + + AC_CONFIG_HEADERS([config.h:config.in]) + +-LT_PREREQ([2.4.2]) ++LT_PREREQ([2.4]) + LT_INIT([disable-static win32-dll]) + + #shared library versioning