Date: Thu, 09 Apr 2015 22:43:35 +1000 From: Dewayne Geraghty <dewayne.geraghty@heuristicsystems.com.au> To: freebsd-ports@freebsd.org Subject: Re: openssl and bash libcrypto Message-ID: <552673F7.70102@heuristicsystems.com.au> In-Reply-To: <CA%2B7WWSdh6Mi3VGkEidK4_MCrzx4q2-YS87-YTsS8UmtOT36tUQ@mail.gmail.com> References: <552657AC.1020802@ish.com.au> <CA%2B7WWSdh6Mi3VGkEidK4_MCrzx4q2-YS87-YTsS8UmtOT36tUQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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> wrote: >> Starting in the last week or so, several different applications are exhibiting 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/libcrypto.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 asterisk. The builds are done in poudriere with the make flags: >> >> WITH_OPENSSL_PORT=yes >> >> >> I've tried updating to the latest 10.1-RELEASE-p6, although it is possible that that is exactly what caused the problem in the first place when the 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 figure 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 what 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 follow‐ > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?552673F7.70102>