On Mon, Jun 1, 2015 at 7:17 PM, Benjamin Kaduk <kaduk at 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. > > -BenRumour 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? ;) 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. -Kimmo
Kimmo Paasiala:> 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? ;)Curious why this is a rumor? Open source operating systems should be developed transparently, shouldn't they?> 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.I'd be happy just to to 'make buildworld -DWITHOUT_OPENSSL'. Roger Marquis
(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
On 6/2/15 12:25 AM, Kimmo Paasiala wrote:> On Mon, Jun 1, 2015 at 7:17 PM, Benjamin Kaduk <kaduk at 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? ;) > > 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.I'd like to take a bunch of libraries out of base, But That is not the same as making them "ports". I've said before that I thik we need something half way between. using the ports/pkg mechanism, but from an administrative point of view, still a part of base.. Easier to upgrade, but yet, still considered part of the base distribution. in other words, currently a failure in ncurses can stop a release from shipping, and in my world a failure in "base pkg ncurses" would still have that ability, but would be delivered as a separately upgradable pkg. i.e. some pkgs are more important than others.> > -Kimmo > _______________________________________________ > freebsd-security at freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe at freebsd.org" > >
On 6/1/2015 11:25 AM, Kimmo Paasiala wrote:> On Mon, Jun 1, 2015 at 7:17 PM, Benjamin Kaduk <kaduk at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: <http://lists.freebsd.org/pipermail/freebsd-security/attachments/20150602/3db07859/attachment.sig>