From owner-freebsd-ports@FreeBSD.ORG Thu Apr 9 15:15:25 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88B69806 for ; Thu, 9 Apr 2015 15:15:25 +0000 (UTC) Received: from mail-vn0-x22f.google.com (mail-vn0-x22f.google.com [IPv6:2607:f8b0:400c:c0f::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 333BD860 for ; Thu, 9 Apr 2015 15:15:25 +0000 (UTC) Received: by vnbf129 with SMTP id f129so21609230vnb.9 for ; Thu, 09 Apr 2015 08:15:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=n3BHuE6TdOI1ROKgvMNU2c1ZV7sCkDkdcncNsMVo2zE=; b=EnsmMCSkw/pBUx31oFq5Bq6Jjfw9D4wJNJ2yByonDb3xlddxuvFxmGFN+PoiNiqL0M PG6kj18LnnaBlPtws+4vCVsUDEMsVttzNICbyzfL2UQIqLcZgnC/TtiIp9Jebyh3vsB9 524T4XBUwoSTMEEYKl9e5Gm+3GeD9FEBpHjQttRFOfaD93+i9sOXUl93q7gQ7acwPBG0 VS8AQzZheCKZQIVOLIUb8gUaFI6W7iZTe3tlH1+i7L8MvJFgzfK3Y/RqTa1PUJtFsQp7 tipm/qLoMKrJNVZ/hlG0k0RrPjXeC5mUMtmHLpU1cBA0tbRKHBXA6A+KoaZaxM/XIKX0 Lp0w== X-Received: by 10.52.26.47 with SMTP id i15mr5490987vdg.56.1428592523788; Thu, 09 Apr 2015 08:15:23 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id p12sm2626814vds.23.2015.04.09.08.15.20 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2015 08:15:22 -0700 (PDT) Sender: Baptiste Daroussin Date: Thu, 9 Apr 2015 17:15:18 +0200 From: Baptiste Daroussin To: Kimmo Paasiala Subject: Re: openssl and bash libcrypto Message-ID: <20150409151518.GS95321@ivaldir.etoilebsd.net> References: <552657AC.1020802@ish.com.au> <552673F7.70102@heuristicsystems.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4ZVTVymsHR1TEBjP" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-ports , Dewayne Geraghty X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 15:15:25 -0000 --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 > wrote: > > > > On 9/04/2015 10:02 PM, Kimmo Paasiala wrote: > >> On Thu, Apr 9, 2015 at 1:42 PM, Aristedes Maniatis 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--