Date: Mon, 1 Jun 2015 19:03:59 +0200 From: Franco Fichtner <franco@lastsummer.de> To: Benjamin Kaduk <kaduk@MIT.EDU> Cc: Kimmo Paasiala <kpaasial@gmail.com>, freebsd-security <freebsd-security@freebsd.org>, Don Lewis <truckman@freebsd.org>, spil.oss@gmail.com Subject: Re: scope of private libraries Message-ID: <2C5684F6-5D01-42BE-A7BD-13DD88040128@lastsummer.de> In-Reply-To: <alpine.GSO.1.10.1506011238440.22210@multics.mit.edu> 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> <alpine.GSO.1.10.1506011238440.22210@multics.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 01 Jun 2015, at 18:42, Benjamin Kaduk <kaduk@MIT.EDU> wrote: > > (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. I like this. Why not start with OpenSSL in base and make the OpenSSL port mandatory? Still struggling with the LibreSSL integration, which is quite obscured by the base library with recent holes uncovered that also applied to OpenSSL from ports. The fallback to OpenSSL from base creates a convenience scenario that hurts (and already has hurt) security. This makes security-related ports updates faster and reduces the attack surface of the base system. Everthing is moving to pkgng anyway as far as the pkgng team is concerned. ;) As a side note, does pkgng really have to depend on base OpenSSL; does it have to depend on a full-blown SSL library? Cheers, Franco
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2C5684F6-5D01-42BE-A7BD-13DD88040128>