Date: Thu, 9 Apr 2015 17:15:18 +0200 From: Baptiste Daroussin <bapt@FreeBSD.org> To: Kimmo Paasiala <kpaasial@gmail.com> Cc: freebsd-ports <freebsd-ports@freebsd.org>, Dewayne Geraghty <dewayne.geraghty@heuristicsystems.com.au> Subject: Re: openssl and bash libcrypto Message-ID: <20150409151518.GS95321@ivaldir.etoilebsd.net> In-Reply-To: <CA%2B7WWSfR_=iKfJ9kvb6jMg=VaVAdep55upuP%2B2zDxCBT%2BpwgmA@mail.gmail.com> References: <552657AC.1020802@ish.com.au> <CA%2B7WWSdh6Mi3VGkEidK4_MCrzx4q2-YS87-YTsS8UmtOT36tUQ@mail.gmail.com> <552673F7.70102@heuristicsystems.com.au> <CA%2B7WWSfR_=iKfJ9kvb6jMg=VaVAdep55upuP%2B2zDxCBT%2BpwgmA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--4ZVTVymsHR1TEBjP Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 09, 2015 at 05:52:48PM +0300, Kimmo Paasiala wrote: > 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> wr= ote: > >>> Starting in the last week or so, several different applications are e= xhibiting 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/l= ibcrypto.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-el= f.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=3Dyes > >>> > >>> > >>> I've tried updating to the latest 10.1-RELEASE-p6, although it is pos= sible 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 betwee= n 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 librarie= s"? > >>> * 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 w= hat 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=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.or= g" > >> > >> > >> > > 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. > > >=20 > Aah yes, it's no-go then if it breaks pkg(8)... >=20 > 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. >=20 There is an ongoing work to enforce libcrypto/libssl from ports for anythin= g but pkg(8) we hope to be able to make that happen soon, but of cour $soon is undefined :) Best regards, Bapt --4ZVTVymsHR1TEBjP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlUml4YACgkQ8kTtMUmk6Ex/dwCguYazWqakOgUvI+ao0KppsqPw eIwAnAk40gETyTJ37MhO+732Y7Mvyknl =Ds5y -----END PGP SIGNATURE----- --4ZVTVymsHR1TEBjP--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150409151518.GS95321>