Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 1 Jun 2015 12:42:44 -0400 (EDT)
From:      Benjamin Kaduk <kaduk@MIT.EDU>
To:        Kimmo Paasiala <kpaasial@gmail.com>
Cc:        Don Lewis <truckman@freebsd.org>, freebsd-security <freebsd-security@freebsd.org>
Subject:   scope of private libraries
Message-ID:  <alpine.GSO.1.10.1506011238440.22210@multics.mit.edu>
In-Reply-To: <CA%2B7WWSc47cH_C%2BJCFNv22onuf-V=mFNQ%2BU96Gx_vUm-1YU2OdQ@mail.gmail.com>
References:  <201506010138.t511cp2P088983@gw.catspoiler.org> <alpine.GSO.1.10.1506011214350.22210@multics.mit.edu> <CA%2B7WWSc47cH_C%2BJCFNv22onuf-V=mFNQ%2BU96Gx_vUm-1YU2OdQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
(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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.GSO.1.10.1506011238440.22210>