Message ID | 48db419f-0d5d-a9b9-6f55-dffc5d4fbbe5@rfc2549.org |
---|---|
State | Superseded |
Headers | show |
Series | [Openvpn-devel] wolfSSL unit test failures | expand |
Hi, On Thu, Aug 18, 2022 at 12:40:09AM +0200, Arne Schwabe wrote: > From 02d4c4d8444188bdf32a054171ea7e20cc7c12ff Mon Sep 17 00:00:00 2001 > From: Arne Schwabe <arne@rfc2549.org> > Date: Thu, 11 Aug 2022 19:27:12 +0200 > Subject: [PATCH] Add wolfSSL to github actions > > I just want to see the world burn a little bit I'm not merging this as of today, because I do not really want to get an error notification from GH on every build. As soon as this is fixed in upstream WolfSSL, it's a good addition to our test suite. gert
Hi Arne, thank you for your report. In the future, please send reports to support@wolfssl.com to guarantee the fastest possible response. This also helps us track bug reports. I have forwarded this report for you. Either I or someone else will investigate this and get back to you with a solution soon. Sincerely Juliusz On 18/08/2022 00:40, Arne Schwabe wrote: > Hey, > > currently we still have test failures in wolfSSL in > > EVP_PKEY_CTX_new with clang asan. Github action patch that reproduces > this also attached. With the OpenVPN 2.6 release coming up in the next > months it would be good if these can be fixed. These look like problems > in the upstream wolfSSL code. > > > Details are below: > > ================================================================= > ==19723==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 160 byte(s) in 4 object(s) allocated from: > #0 0x49604d in malloc > (/home/runner/work/openvpn/openvpn/tests/unit_tests/openvpn/crypto_testdriver+0x49604d) > #1 0x7f64e8318291 in wolfSSL_EVP_PKEY_CTX_new > (/usr/local/lib/libwolfssl.so.34+0x9e291) > > Indirect leak of 400 byte(s) in 2 object(s) allocated from: > #0 0x49604d in malloc > (/home/runner/work/openvpn/openvpn/tests/unit_tests/openvpn/crypto_testdriver+0x49604d) > #1 0x7f64e833c537 in wolfSSL_EVP_PKEY_new_ex > (/usr/local/lib/libwolfssl.so.34+0xc2537) > > Indirect leak of 240 byte(s) in 2 object(s) allocated from: > #0 0x49604d in malloc > (/home/runner/work/openvpn/openvpn/tests/unit_tests/openvpn/crypto_testdriver+0x49604d) > #1 0x7f64e82b4ac2 in _InitRng.isra.0 > (/usr/local/lib/libwolfssl.so.34+0x3aac2) > > Indirect leak of 118 byte(s) in 2 object(s) allocated from: > #0 0x49604d in malloc > (/home/runner/work/openvpn/openvpn/tests/unit_tests/openvpn/crypto_testdriver+0x49604d) > #1 0x7f64e833c72b in wolfSSL_EVP_PKEY_new_mac_key > (/usr/local/lib/libwolfssl.so.34+0xc272b) > > SUMMARY: AddressSanitizer: 918 byte(s) leaked in 10 allocation(s). > FAIL: crypto_testdriver >
Am 18.08.22 um 17:21 schrieb Juliusz Sosinowicz: > Hi Arne, > > thank you for your report. In the future, please send reports to > support@wolfssl.com to guarantee the fastest possible response. This > also helps us track bug reports. I have forwarded this report for you. > > Either I or someone else will investigate this and get back to you with > a solution soon. > To be honest, I do not really have interest in that. We ourselves do not use wolfSSL at all with OpenVPN and we included wolfSSL with the promise from wolfSSL (the company) that they will maintain the implementation for OpenVPN. I merely send this as a reminder to fix the current with wolfSSL so OpenVPN 2.6 can be released with wolfSSL support. But if we have to spend time going through support requests and to keep something maintained that we ourselves have no intrinsic motivation to support, I will advocate to set/change the status of wolfSSL in OpenVPN to "unmaintained". Arne
Hi Everyone, this leak has been fixed in wolfSSL in this pull request: https://github.com/wolfSSL/wolfssl/pull/5514 Sincerely Juliusz On 18/08/2022 00:40, Arne Schwabe wrote: > Hey, > > currently we still have test failures in wolfSSL in > > EVP_PKEY_CTX_new with clang asan. Github action patch that reproduces > this also attached. With the OpenVPN 2.6 release coming up in the next > months it would be good if these can be fixed. These look like problems > in the upstream wolfSSL code. > > > Details are below: > > ================================================================= > ==19723==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 160 byte(s) in 4 object(s) allocated from: > #0 0x49604d in malloc > (/home/runner/work/openvpn/openvpn/tests/unit_tests/openvpn/crypto_testdriver+0x49604d) > #1 0x7f64e8318291 in wolfSSL_EVP_PKEY_CTX_new > (/usr/local/lib/libwolfssl.so.34+0x9e291) > > Indirect leak of 400 byte(s) in 2 object(s) allocated from: > #0 0x49604d in malloc > (/home/runner/work/openvpn/openvpn/tests/unit_tests/openvpn/crypto_testdriver+0x49604d) > #1 0x7f64e833c537 in wolfSSL_EVP_PKEY_new_ex > (/usr/local/lib/libwolfssl.so.34+0xc2537) > > Indirect leak of 240 byte(s) in 2 object(s) allocated from: > #0 0x49604d in malloc > (/home/runner/work/openvpn/openvpn/tests/unit_tests/openvpn/crypto_testdriver+0x49604d) > #1 0x7f64e82b4ac2 in _InitRng.isra.0 > (/usr/local/lib/libwolfssl.so.34+0x3aac2) > > Indirect leak of 118 byte(s) in 2 object(s) allocated from: > #0 0x49604d in malloc > (/home/runner/work/openvpn/openvpn/tests/unit_tests/openvpn/crypto_testdriver+0x49604d) > #1 0x7f64e833c72b in wolfSSL_EVP_PKEY_new_mac_key > (/usr/local/lib/libwolfssl.so.34+0xc272b) > > SUMMARY: AddressSanitizer: 918 byte(s) leaked in 10 allocation(s). > FAIL: crypto_testdriver >
On 18/08/2022 22:06, Arne Schwabe wrote: > > But if we have to spend time going through support requests and to keep > something maintained that we ourselves have no intrinsic motivation to > support, I will advocate to set/change the status of wolfSSL in OpenVPN > to "unmaintained". Agreed. If wolfSSL support is expected to work in OpenVPN, those interested in wolfSSL need to be far more active and follow the OpenVPN development to ensure the support still functions and performs as expected. The wolfSSL support has so far had quite little impact on growing the OpenVPN user or development base, so there is little motivation or even reasons for the OpenVPN community to take ownership of this. Don't expect the wolfSSL support to be tested much at all by the community developers. On the other side, we do see that wolfSSL has more a benefit of slamming the "works with OpenVPN" label on wolfSSL. But don't count on the OpenVPN community doing the grunt work for wolfSSL. Either be more actively involved - or accept we will move it to an unmaintained status - plausibly removing it if it stays broken for a longer time.
diff --git a/.github/workflows/build.yaml b/.github/workflows/build.yaml index 2a9a4e946..9c640cc7f 100644 --- a/.github/workflows/build.yaml +++ b/.github/workflows/build.yaml @@ -34,6 +34,48 @@ jobs: - name: Set job status run: test ! -s uncrustify-changes.patch working-directory: openvpn + wolfssl: + strategy: + fail-fast: false + matrix: + os: [ubuntu-20.04] + ssllib: [wolfssl] + + name: "gcc - ${{matrix.os}} - ${{matrix.ssllib}}" + + runs-on: ${{matrix.os}} + steps: + - name: Install dependencies + run: sudo apt update && sudo apt install -y liblzo2-dev libpam0g-dev liblz4-dev linux-libc-dev man2html clang libcmocka-dev python3-docutils libtool automake autoconf libmbedtls-dev pkg-config libcap-ng-dev + - name: "wolfSSL: checkout" + uses: actions/checkout@v3 + with: + path: wolfssl + repository: wolfSSL/wolfssl + - name: "wolfSSL: autoconf" + run: autoreconf -fvi + working-directory: wolfssl + - name: "wolfSSL: configure" + run: ./configure --enable-openvpn + working-directory: wolfssl + - name: "wolfSSL: make all" + run: make -j3 + working-directory: wolfssl + - name: "wolfSSL: make install" + run: sudo make install + working-directory: wolfssl + - name: "ldconfig" + run: sudo ldconfig + - name: Checkout OpenVPN + uses: actions/checkout@v3 + - name: autoconf + run: autoreconf -fvi + - name: configure + run: CFLAGS="-fsanitize=address -fno-omit-frame-pointer -O2" CC=clang ./configure --with-crypto-library=${{matrix.ssllib}} + - name: make all + run: make -j3 + - name: make check + run: make check mingw: strategy: