Summary: | www/node 10.0.0: SSL routines:tls_process_key_exchange:wrong signature length on i386 only | ||
---|---|---|---|
Product: | Ports & Packages | Reporter: | Marcin Cieślak <saper> |
Component: | Individual Port(s) | Assignee: | Bradley T. Hughes <bhughes> |
Status: | Closed FIXED | ||
Severity: | Affects Many People | CC: | robbelics |
Priority: | --- | Flags: | bugzilla:
maintainer-feedback?
(bhughes) |
Version: | Latest | ||
Hardware: | Any | ||
OS: | Any |
Description
Marcin Cieślak
2018-05-10 22:16:32 UTC
I can also reproduce this on my 11.1-RELEASE i386 jail on a 12.0-CURRENT host. I think I have a fix, I need to verify it on armv[67] and aarch64 first. The build broke on my arm jails, so I will need more time to work on it. I'll keep you posted. Can you share your idea? Do you think it's an upstream issue? I hope it is not a 32-bit compatibility problem similar to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=178881 I couldn't test unbundled OpenSSL in Poudriere because Python does not like the newest OpenSSL. The idea is to stop using the BSD-x86_64 no-asm config for everything. I had thought I managed to get the build working on all archs with this config, but it assumes a 64-bit arch, which of course breaks on i386 and 32-bit arm. This is both an upstream issue and a port issue. Upstream, they only provide a BSD-x86_64 arch config, so the port is having to work around the lack of a 32-bit config by trying to re-use other configs, which doesn't completely work. Once I make sense of everything, I plan to open more upstream issues and pull requests to get the build into shape without the need for multiple patches in the port. I have already reported the lack of a 32-bit BSD-x86 config: https://github.com/nodejs/node/issues/20326 A commit references this bug: Author: bhughes Date: Sun May 13 08:21:49 UTC 2018 New revision: 469781 URL: https://svnweb.freebsd.org/changeset/ports/469781 Log: www/node: fix SSL/TLS on i386 The upgrade to v10.0.0 included significant changes to the OpenSSL dependency in Node.js, in particular how the build was configured. Upstream does not include a BSD-x86 config anymore, so the www/node port ended up using the BSD-x86_64 no-asm config for all builds except x86_64 (which used the asm optimized config). This was a mistake, causing all 32-bit archs to build OpenSSL configured for a 64-bit architecture, and it causes problems with SSL/TLS as described in PR 228135. Change the build config to not use BSD-x86_64 no-asm for 32-bit i386 and arm builds, falling back to the generic linux-elf configuration instead. Patches remove Linux specific libraries (-ldl) and keep the CFLAGS the same as the BSD config. PR: 228135 Reported by: Marcin Cie\xc5\x9blak <saper@saper.info> Changes: head/www/node/Makefile head/www/node/files/patch-deps_openssl_config_archs_linux-elf_no-asm_openssl-cl.gypi head/www/node/files/patch-deps_openssl_config_archs_linux-elf_no-asm_openssl.gypi head/www/node/files/patch-deps_openssl_config_bn__conf__no-asm.h head/www/node/files/patch-deps_openssl_config_dso__conf__no-asm.h head/www/node/files/patch-deps_openssl_config_opensslconf__no-asm.h head/www/node/files/patch-deps_openssl_openssl-cl__no__asm.gypi head/www/node/files/patch-deps_openssl_openssl__no__asm.gypi I just committed a fix, but I would appreciate if you could also test and confirm that it works for you as well. :) (In reply to Bradley T. Hughes from comment #7) About this same time, I updated node on two machines. One worked fine, the other, some time later, did not update. I don't know if this is related: cc '-DOPENSSL_NO_HW' '-DDSO_DLFCN' '-DHAVE_DLFCN_H' '-DNDEBUG' '-DOPENSSL_THREADS' '-DOPENSSL_NO_DYNAMIC_ENGINE' '-DOPENSSL_PIC' '-DOPENSSL_BN_ASM_PART_WORDS' '-DOPENSSL_IA32_SSE2' '-DOPENSSL_BN_ASM_MONT' '-DOPENSSL_BN_ASM_GF2m' '-DSHA1_ASM' '-DSHA256_ASM' '-DSHA512_ASM' '-DRC4_ASM' '-DMD5_ASM' '-DRMD160_ASM' '-DAES_ASM' '-DVPAES_ASM' '-DWHIRLPOOL_ASM' '-DGHASH_ASM' '-DECP_NISTZ256_ASM' '-DPADLOCK_ASM' '-DPOLY1305_ASM' '-DOPENSSLDIR="/etc/ssl"' '-DENGINESDIR="/dev/null"' '-DTERMIOS' -I../deps/openssl/openssl -I../deps/openssl/openssl/include -I../deps/openssl/openssl/crypto -I../deps/openssl/openssl/crypto/include -I../deps/openssl/openssl/crypto/modes -I../deps/openssl/config -I../deps/openssl/config/archs/linux-elf/asm -I../deps/openssl/config/archs/linux-elf/asm/include -I../deps/openssl/config/archs/linux-elf/asm/crypto -I../deps/openssl/config/archs/linux-elf/asm/crypto/include/internal -pthread -Wall -Wextra -Wno-unused-parameter -m32 -Wall -O3 -pthread -DL_ENDIAN -fomit-frame-pointer -Wno-missing-field-initializers -Wno-old-style-declaration -O3 -fno-omit-frame-pointer -MMD -MF /usr/ports/www/node/work/node-v10.1.0/out/Release/.deps//usr/ports/www/node/work/node-v10.1.0/out/Release/obj.target/openssl/deps/openssl/openssl/ssl/bio_ssl.o.d.raw -isystem /usr/local/include -O2 -pipe -fstack-protector -isystem /usr/local/include -fno-strict-aliasing -c -o /usr/ports/www/node/work/node-v10.1.0/out/Release/obj.target/openssl/deps/openssl/openssl/ssl/bio_ssl.o ../deps/openssl/openssl/ssl/bio_ssl.c warning: unknown warning option '-Wno-old-style-declaration'; did you mean '-Wno-out-of-line-declaration'? [-Wunknown-warning-option] In file included from ../deps/openssl/openssl/ssl/bio_ssl.c:14: In file included from ../deps/openssl/openssl/include/openssl/crypto.h:22: In file included from ../deps/openssl/openssl/include/openssl/e_os2.h:13: In file included from ../deps/openssl/openssl/include/openssl/opensslconf.h:1: In file included from ../deps/openssl/openssl/include/../../config/opensslconf.h:9: ../deps/openssl/config/./opensslconf_asm.h:112:11: fatal error: './archs/BSD-x86/asm/include/openssl/opensslconf.h' file not found # include "./archs/BSD-x86/asm/include/openssl/opensslconf.h" ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 warning and 1 error generated. gmake[3]: *** [deps/openssl/openssl.target.mk:801: /usr/ports/www/node/work/node-v10.1.0/out/Release/obj.target/openssl/deps/openssl/openssl/ssl/bio_ssl.o] Error 1 rm 85b29271a4bb91f75d9ce011e25110ea11ec22c1.intermediate gmake[2]: *** [Makefile:87: node] Error 2 gmake[2]: Leaving directory '/usr/ports/www/node/work/node-v10.1.0' ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1 Stop. make[1]: stopped in /usr/ports/www/node *** Error code 1 Rob: that error shouldn't happen, since the port patches opensslconf_asm.h to comment out line 112 that includes "archs/BSD-x86/asm/include/openssl/opensslconf.h". See files/patch-deps_openssl_config_opensslconf__asm.h Do you have any local modifications to your ports tree? (In reply to Bradley T. Hughes from comment #9) I have made no changes to this or portsnap in many years but I've used node for many years also. Can you suggest where I might look for anything that could affect this? Hi, I run into the same issue. I think the port is patching only "no-asm" versions and this is "asm". After "make patch" I have line 112 like this: # include "./archs/BSD-x86/asm/include/openssl/opensslconf.h" besides I don't think that commenting out "#elif" is useful - it should fall back to the last #else and will try to use some Linux stuff. Besides we are using C compiler here, I think we should not use "//" comments... A commit references this bug: Author: bhughes Date: Sun May 13 20:30:04 UTC 2018 New revision: 469828 URL: https://svnweb.freebsd.org/changeset/ports/469828 Log: www/node: fix build on i386 Add patch files missing from r469781, which ensure that the Node.js build on i386 falls back to the linux-elf OpenSSL config. PR: 228135 Reported by: Marcin Cieslak <saper@saper.info> Changes: head/www/node/files/patch-deps_openssl_config_archs_linux-elf_asm_openssl-cl.gypi head/www/node/files/patch-deps_openssl_config_archs_linux-elf_asm_openssl.gypi head/www/node/files/patch-deps_openssl_config_bn__conf__asm.h head/www/node/files/patch-deps_openssl_config_dso__conf__asm.h head/www/node/files/patch-deps_openssl_config_opensslconf__asm.h head/www/node/files/patch-deps_openssl_openssl__no__asm.gypi Thanks for the feedback, Rob and Marcin. Found out that I forgot to `svn add` several new patch files. They are committed now, please try again :) (In reply to Bradley T. Hughes from comment #13) That fixed it for me. Thanks for your work on all this. And thank you for taking the time to report it :) I'm closing this specific issue now, but will be submitting several changes upstream in the next few days and weeks. |