On 6/1/2015 11:25 AM, Kimmo Paasiala wrote: > On Mon, Jun 1, 2015 at 7:17 PM, Benjamin Kaduk <ka...@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=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 >>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200555>. >> >> 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? ;)
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. > > 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
signature.asc
Description: OpenPGP digital signature
