From owner-freebsd-security@FreeBSD.ORG Mon Jun 1 16:44:56 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C12ACA1A for ; Mon, 1 Jun 2015 16:44:56 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D02816F0 for ; Mon, 1 Jun 2015 16:44:56 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-248-228.lns20.per4.internode.on.net [121.45.248.228]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t51Giq7J096410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 1 Jun 2015 09:44:55 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <556C8BFE.708@freebsd.org> Date: Tue, 02 Jun 2015 00:44:46 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: avoiding base openssl when building ports References: <201506010138.t511cp2P088983@gw.catspoiler.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 16:44:56 -0000 On 6/2/15 12:25 AM, Kimmo Paasiala wrote: > On Mon, Jun 1, 2015 at 7:17 PM, Benjamin Kaduk wrote: >> On Sun, 31 May 2015, Don Lewis wrote: >> >>> The big culprit turned out to be ftp/curl. Even though >>> WITH_OPENSSL_PORT=yes caused it to add the openssl port as a build and >>> run dependency, it was silently getting linked to openssl from base. The >>> cause of that problem is that the default GSSAPI_BASE option adds >>> -L/usr/lib near the start of LDFLAGS, so the linker finds the base >>> openssl libraries instead of the ones from the port. I worked around >>> that problem by switching to GSSAPI_NONE, though I tested that the other >>> GSSAPI_* options also work correctly. There is a sanity check in the >>> Makefile that attempts to catch this conflict, but it does not work >>> correctly. See >>> . >> My apologies for semi-hijacking your thread, but I am starting to wonder >> whether the base Heimdal (and GSSAPI) should be converted to be a private >> library. Since I am living in a MIT krb5 world, which is incompatible >> with the Heimdal libraries, I end up having some trouble trying to force >> various things to be used from base vs. ports. >> >> Making the Heimdal in base into private libraries would "solve" the >> problem with ftp/curl, but only insamuch as it would make the GSSAPI_BASE >> option useless and require a GSSAPI from ports. >> >> -Ben > > Rumour is that something like that is going to happen with all of the > problematic libraries by making them private. If someone with inside > knowledge could confirm these rumours? ;) > > This leads to another question. Where is the line going to be drawn > which libraries in the base system should be private? There are > certainly some of them that have to be public like libc and the > support libraries like libusb. There is certainly no sense in making > the ports system use full set of its own libraries for everything > either. I'd like to take a bunch of libraries out of base, But That is not the same as making them "ports". I've said before that I thik we need something half way between. using the ports/pkg mechanism, but from an administrative point of view, still a part of base.. Easier to upgrade, but yet, still considered part of the base distribution. in other words, currently a failure in ncurses can stop a release from shipping, and in my world a failure in "base pkg ncurses" would still have that ability, but would be delivered as a separately upgradable pkg. i.e. some pkgs are more important than others. > > -Kimmo > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" > >