Date: Tue, 02 Jun 2015 10:17:38 -0500 From: Bryan Drewery <bdrewery@FreeBSD.org> To: Kimmo Paasiala <kpaasial@gmail.com>, Benjamin Kaduk <kaduk@mit.edu> Cc: freebsd-security <freebsd-security@freebsd.org>, Don Lewis <truckman@freebsd.org> Subject: Re: avoiding base openssl when building ports Message-ID: <556DC912.1060808@FreeBSD.org> 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
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --A14iunkffbF9ccacKIouEgWGdcimtBGxT Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 6/1/2015 11:25 AM, Kimmo Paasiala wrote: > On Mon, Jun 1, 2015 at 7:17 PM, Benjamin Kaduk <kaduk@mit.edu> wrote: >> On Sun, 31 May 2015, Don Lewis wrote: >> >>> The big culprit turned out to be ftp/curl. Even though >>> WITH_OPENSSL_PORT=3Dyes 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 ot= her >>> 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 >>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D200555>. >> >> My apologies for semi-hijacking your thread, but I am starting to wond= er >> whether the base Heimdal (and GSSAPI) should be converted to be a priv= ate >> 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 for= ce >> 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_B= ASE >> option useless and require a GSSAPI from ports. >> >> -Ben >=20 >=20 > 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? ;) I don't know why you call this a rumor. It's an ongoing effort for over a year now. It's just been slow due to lack of consensus and other technical and social issues. It's not that we try to keep things secret here, it's just that we tend to discuss on IRC and then if the issue is big enough discuss it on arch@ or just use a phabricator review. If it is trivial and there is no concern of problems then it is just committed. It's simply not practical to discuss everything in email. Usually we get an itch to make a library private and discuss it quickly in a private message and then produce a patch. >=20 > 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. Everything we do is wrong. Obviously we can't make libc private. In the current scheme only 3rd party libraries or libraries that are only needed for internal build tools or libraries which are constant security concerns are really eligible for becoming private libs. In a correct world everything in the base system would be a "package" in the same sense as ports has "packages". Libc too would be a "package". We would have 1 and only 1 OpenSSL "package" rather than a private one and port one. When this discussion comes up people tend to jump to the wrong conclusions. This is not suggesting making the base system only a kernel and "good luck go run pkg". It's just saying everything would be packaged and most likely due to POLA be the same installed files we provide today in the base world system. Our base system and ports system frameworks are severely lacking to make this all possible today though. We also have social hurdles. The way we're doing private libs now is flawed as is since it easily leaks these private libs into the public linker space. For example, if we made OpenSSL private in the base then libfetch would be providing OpenSSL private lib links when libfetch was linked in. This defeats the purpose of having OpenSSL as private and can cause collisions. Regards, Bryan Drewery --A14iunkffbF9ccacKIouEgWGdcimtBGxT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJVbckSAAoJEDXXcbtuRpfP5BAH/jfnfsSaHFXR2MJTP0pgke4O GiOlcdq3ioyG9gVsf9fXZZaYn/7J9//r+hb/v6FlnWYsOIc4/ylGPAkENXuBVN7d 8nhKUai9OYGllGZ9umOPm44gLysFkBm1wGfpOY6FkeEx3yQNOQzmB9Jb4o7EdtZ7 pKxvcrVDQ32Osz7xufp8/lbYXrS8caWoLmbOfIdCnrLZHrxmUhYznpLQi2BIQ/pp 7HcvV5bxitE5I+HnBHCccSLHsPu8yw+JpwOd+brYCWoFuCgrCaDfpUY7wCPDHtj0 fJAcYSNC28X2O0uMbkYV2dPqxs0B/e2iebP5PGdgpuliXMXxmqDrbbHQFhgthpw= =0pY4 -----END PGP SIGNATURE----- --A14iunkffbF9ccacKIouEgWGdcimtBGxT--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?556DC912.1060808>