Date: Thu, 9 Apr 2015 17:52:48 +0300 From: Kimmo Paasiala <kpaasial@gmail.com> To: Dewayne Geraghty <dewayne.geraghty@heuristicsystems.com.au> Cc: freebsd-ports <freebsd-ports@freebsd.org> Subject: Re: openssl and bash libcrypto Message-ID: <CA%2B7WWSfR_=iKfJ9kvb6jMg=VaVAdep55upuP%2B2zDxCBT%2BpwgmA@mail.gmail.com> In-Reply-To: <552673F7.70102@heuristicsystems.com.au> References: <552657AC.1020802@ish.com.au> <CA%2B7WWSdh6Mi3VGkEidK4_MCrzx4q2-YS87-YTsS8UmtOT36tUQ@mail.gmail.com> <552673F7.70102@heuristicsystems.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Apr 9, 2015 at 3:43 PM, Dewayne Geraghty <dewayne.geraghty@heuristicsystems.com.au> wrote: > > On 9/04/2015 10:02 PM, Kimmo Paasiala wrote: >> On Thu, Apr 9, 2015 at 1:42 PM, Aristedes Maniatis <ari@ish.com.au> wrot= e: >>> Starting in the last week or so, several different applications are exh= ibiting the same symptoms of broken libcrypto libraries. >>> >>> (gdb) core bash.core >>> Core was generated by `bash'. >>> Program terminated with signal 11, Segmentation fault. >>> >>> (gdb) bt >>> #0 0x00000008029cafe5 in OPENSSL_ia32_cpuid () from /usr/local/lib/lib= crypto.so.8 >>> #1 0x00000008033cf0b9 in OPENSSL_ia32cap_loc () from /lib/libcrypto.so= .7 >>> #2 0x00000008032d584e in _init () from /lib/libcrypto.so.7 >>> #3 0x00007fffffffd7c0 in ?? () >>> #4 0x00000008006d66bf in r_debug_state () from /libexec/ld-elf.so.1 >>> #5 0x00000008006dad87 in _rtld_get_stack_prot () from /libexec/ld-elf.= so.1 >>> #6 0x00000008006d7ad3 in dlopen () from /libexec/ld-elf.so.1 >>> #7 0x0000000800e5c436 in _nsdbtaddsrc () from /lib/libc.so.7 >>> #8 0x0000000800e563c9 in _nsyyparse () from /lib/libc.so.7 >>> #9 0x0000000800e5cab1 in nsdispatch () from /lib/libc.so.7 >>> #10 0x0000000800e49ebe in getpwuid () from /lib/libc.so.7 >>> #11 0x0000000800e49cbf in getpwnam () from /lib/libc.so.7 >>> >>> >>> Although that symptom is in bash, I've got the exact same symptoms in a= sterisk. The builds are done in poudriere with the make flags: >>> >>> WITH_OPENSSL_PORT=3Dyes >>> >>> >>> I've tried updating to the latest 10.1-RELEASE-p6, although it is possi= ble that that is exactly what caused the problem in the first place when th= e poudriere jail was updated to that release. >>> >>> The function calls mention ia32 but this box is purely 64bit. >>> >>> >>> I've seen recent discussions about the problems that confusion between = core openssl and ports openssl can cause. But I can't for the life of me fi= gure how to avoid this problem. >>> >>> * Should bash be built with "Build static executables and/or libraries"= ? >>> * Should I stop trying to use openssl from ports until this is fixed? >>> * Why is /lib/libcrypto.so.7 calling /usr/local/lib/libcrypto.so.8 ? >>> >>> I've tried so many different combinations of settings, I don't know wha= t to try next. >>> >>> Thanks >>> Ari >>> >>> >>> -- >>> --------------------------> >>> Aristedes Maniatis >>> ish >>> http://www.ish.com.au >>> Level 1, 30 Wilson Street Newtown 2042 Australia >>> phone +61 2 9550 5001 fax +61 2 9550 4001 >>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A >>> >> You could build world with WITHOUT_OPENSSL but that would also disable >> some other needed pieces such as OpenSSH and you'd have to install >> them from ports. >> >> WITHOUT_OPENSSL >> Set to not build OpenSSL. When set, it also enforces the f= ollow=E2=80=90 >> ing options: >> >> WITHOUT_KERBEROS >> WITHOUT_KERBEROS_SUPPORT >> WITHOUT_OPENSSH >> >> When set, the following options are also in effect: >> >> WITHOUT_GSSAPI (unless WITH_GSSAPI is set explicitly) >> _______________________________________________ >> freebsd-ports@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-ports >> To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" >> >> >> > Take care, as: geli, pkg and tar will fail to build, the latter due to > libarchive, and libfetch as also being affected. I went down this path > a few years ago, but stopped when the ability to install > security/openssl into /usr was instituted. (geli only needs openssl > headers). As an FYI, I build all ports using security/openssl though > heimdal and a few others are a challenge because they try/tried to use > base openssl libcom_err.so. > I'd suggest making a backup of the openssl libs (crypto, ssl), > pkg-static and verify /rescue/tar is available, so that you have a > recovery route. > Aah yes, it's no-go then if it breaks pkg(8)... One solution that comes to my mind would be to use two-level namespaces for symbol resolution. The first part would be the module name and the second part the symbol name. Any shared libraries produced by ports(7) would be required to prepend 'ports-' to the module name. This would eliminate any possibility of dynamic symbol clashes between ports and the base system. -Kimmo
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2B7WWSfR_=iKfJ9kvb6jMg=VaVAdep55upuP%2B2zDxCBT%2BpwgmA>