From owner-freebsd-security@FreeBSD.ORG Mon Jun 1 16:47:58 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 F3B08C6A; Mon, 1 Jun 2015 16:47:57 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 89F28172F; Mon, 1 Jun 2015 16:47:57 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190e-f79b96d000000e0e-34-556c8b87dbef Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id B2.8F.03598.78B8C655; Mon, 1 Jun 2015 12:42:47 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t51GgkkX021685; Mon, 1 Jun 2015 12:42:47 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t51Ggj6n028013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Jun 2015 12:42:46 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t51GgifN027840; Mon, 1 Jun 2015 12:42:44 -0400 (EDT) Date: Mon, 1 Jun 2015 12:42:44 -0400 (EDT) From: Benjamin Kaduk To: Kimmo Paasiala cc: Don Lewis , freebsd-security Subject: scope of private libraries In-Reply-To: Message-ID: References: <201506010138.t511cp2P088983@gw.catspoiler.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrAIsWRmVeSWpSXmKPExsUixG6nrtvenRNqcOy/gUXPpidsFusOTGK2 ONnUzOrA7DHj03wWj52z7rIHMEVx2aSk5mSWpRbp2yVwZXQcmsBU8JKr4v/S/awNjHc4uhg5 OCQETCTmP6vpYuQEMsUkLtxbz9bFyMUhJLCYSWLrhQtMEM4GRombK26ygVQJCRxkknh+3wWk WUigXuLhOT+QMIuAlsT3Y6/AStgEVCRmvtkIZosIqEv0n5zFAmIzC8RJzL/5BiwuLKAssevW fGYQm1MgUOLT2mNgcV4BR4mXJ84zQ+zdxihx4OAasCJRAR2J1funsEAUCUqcnPkEaqiWxPLp 21gmMArOQpKahSS1gJFpFaNsSm6Vbm5iZk5xarJucXJiXl5qka6xXm5miV5qSukmRlDAckry 7WD8elDpEKMAB6MSD29Gd3aoEGtiWXFl7iFGSQ4mJVFe58qcUCG+pPyUyozE4oz4otKc1OJD jBIczEoivLJNQDnelMTKqtSifJiUNAeLkjjvph98IUIC6YklqdmpqQWpRTBZGQ4OJQneyC6g RsGi1PTUirTMnBKENBMHJ8hwHqDhJ0FqeIsLEnOLM9Mh8qcYFaXEeZ1BEgIgiYzSPLheWEJ5 xSgO9IowrzBIFQ8wGcF1vwIazAQ0uF0AbHBJIkJKqoFxrWvv4d9PFS4xHSj7cvBK3iqriBL1 l6WHfQ/HH5GTcN5ySmHdn1UlW9hudCiq9PGxlr2cfjX0svDq6f6MG9yMVryTufHQaGbH79yl a8753dGIDlN4mC8fNFm78k95HYuR0dPArbrnFp915RcJetJ5fMeZSkGO+JLLP6WkE9yXsq+0 lz/0+/scJZbijERDLeai4kQAsB0nygMDAAA= 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:47:58 -0000 (was Re: avoiding base openssl when building ports) On Mon, 1 Jun 2015, Kimmo Paasiala wrote: > 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. [changing Subject: in the hopes of preserving Don's original thread...] Again, I am not one of the people implementing private libraries, but one potential motivation for making something private is if the support lifecycle of an upstream vendor project does not match with the support lifecycle for FreeBSD stable releases. If a library is private in FreeBSD, it is more likely to be POLA-compatible to replace it with a new upstream version mid-stable-branch than if it was a public library. Another possible motivator for making something private is if we have a library in base only for a small subset of the features it provides, and we want to prevent external consumers from trying to rely on the broader set of features in that library. This would reduce the support burden for the library in question, since bugs or vulnerabilities in the unused functionality would not be deemed critical. -Ben