Created attachment 167660 [details] v1 net-p2p/transmission-* ports gained WOLFSSL option but it requires security/wolfssl built with --enable-arc4. wolfssl API seems to be inconsistent with its ABI. $ make WITH=WOLFSSL WITHOUT=OPENSSL TRYBROKEN= net-p2p/transmission-cli [...] libtransmission/libtransmission.a(crypto-utils-cyassl.o): In function `tr_rc4_set_key': libtransmission/crypto-utils-cyassl.c:176: undefined reference to `wc_Arc4SetKey' libtransmission/libtransmission.a(crypto-utils-cyassl.o): In function `tr_rc4_process': libtransmission/crypto-utils-cyassl.c:193: undefined reference to `wc_Arc4Process' cc: error: linker command failed with exit code 1 (use -v to see invocation) $ nm -D /usr/local/lib/libwolfssl.so | fgrep 000000000002a630 T wc_Chacha_Process $ fgrep -r Process /usr/local/include /usr/local/include/wolfssl/wolfcrypt/arc4.h:WOLFSSL_API void wc_Arc4Process(Arc4*, byte*, const byte*, word32); /usr/local/include/wolfssl/wolfcrypt/hc128.h:WOLFSSL_API int wc_Hc128_Process(HC128*, byte*, const byte*, word32); /usr/local/include/wolfssl/wolfcrypt/chacha.h:WOLFSSL_API int wc_Chacha_Process(ChaCha* ctx, byte* cipher, const byte* plain, /usr/local/include/wolfssl/wolfcrypt/rabbit.h:WOLFSSL_API int wc_RabbitProcess(Rabbit*, byte*, const byte*, word32);
Ping after maintainer timeout. Maybe ports-secteam can share an opinion. net-p2p/transmission-* only supports RC4 for encryption between peers. ftp/curl doesn't use RC4 with WOLFSSL=on. No other consumers exist in the ports tree. Neither Arch Linux nor Debian pass --enable-arc4, nor do they provide an option to select SSL backend for Transmission. https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=wolfssl https://sources.debian.net/src/wolfssl/3.4.8%2Bdfsg-1/debian/rules/
(In reply to Jan Beich from comment #1) Sorry for the delay. Sometimes a less than ideal fix to address a real world issue is better than an unfixed issue. However, IMHO enabling RC4 this late in the game feels like the wrong direction. Microsoft [1], Chromium [2], and Mozilla [3] and all moving the route of killing the cipher and enabling it today feels like the wrong direction. I would always appreciate a second thought from the rest of the team on this one. [1] https://blogs.windows.com/msedgedev/2015/09/01/ending-support-for-the-rc4-cipher-in-microsoft-edge-and-internet-explorer-11/ [2] https://groups.google.com/a/chromium.org/forum/#!msg/security-dev/kVfCywocUO8/vgi_rQuhKgAJ [3] https://groups.google.com/forum/#!topic/mozilla.dev.platform/JIEFcrGhqSM/discussion
net-p2p/transmission-cli Makefile shows: WOLFSSL_LIB_DEPENDS= libwolfssl.so:security/wolfssl WOLFSSL_CONFIGURE_ON= --with-crypto=cyassl wolfssl Makefile shows: --enable-ripemd --enable-sha512 --enable-opensslcoexist it is done, could be closed.
(In reply to w.schwarzenfeld from comment #3) How did you manage to miss WOLFSSL_BROKEN? Nothing here has been done. We're just at an impasse. recent build log with TRYBROKEN: http://tpaste.us/10OV
Good question, I overlooked it, sorry.
what is the current status? Does ports-secteam have to be active here?
The WOLFSSL option was removed from net-p2p/transmission-cli in ports r514668 for being broken for >3 years. Can we close this bug? It seems there was no other reason to enable RC4 in security/wolfssl.
FWIW, comment 2 rationale is weak. While RC4 is deprecated there're no plans to remove it from OpenSSL (yet) thus break net-p2p/transmission. Given current state[1] of security/wolfssl there's little value in enabling more consumers at this time. May be revised in future as RC4 is also required by OpenSSH and wpa_supplicant. https://github.com/wolfSSL/wolfssl/blob/v4.1.0-stable/configure.ac#L2095-L2098 [1] Some of vulnerabilities found in 2018 or later may affect the version in ports/. https://security-tracker.debian.org/tracker/source-package/wolfssl