Re: avoiding base openssl when building ports
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 ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: avoiding base openssl when building ports
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? ;) 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 ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: avoiding base openssl when building ports
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 ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: avoiding base openssl when building ports
On Mon, 1 Jun 2015, Roger Marquis wrote: 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? I have no concrete data, but something might live as only a rumor if someone is considering making the change and analyzing how much work it would be, before they have any proposal to make or patches for review. 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'. Better to set WITHOUT_SSL=yes in /etc/src.conf (see src.conf(5)). -Ben ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: scope of private libraries
On Mon, 1 Jun 2015, Franco Fichtner wrote: As a side note, does pkgng really have to depend on base OpenSSL; does it have to depend on a full-blown SSL library? Yes. -Ben (From IRC:) efnet / #bsddev / bjk 13:17 () In particular, Franco asked does pkg really need to depend on openssl from base? efnet / #bsddev / bjk 13:17 () To which I believe the answer is yes, but am not authoritative efnet / #bsddev / bapt 13:48 (bapt!~b...@ns3301091.ip-178-32-217.eu) bjk: I'm not reading but the answer is yes efnet / #bsddev / bapt 13:48 (bapt!~b...@ns3301091.ip-178-32-217.eu) pkg needs openssl efnet / #bsddev / bapt 13:48 (bapt!~b...@ns3301091.ip-178-32-217.eu) because of rsa keys efnet / #bsddev / bapt 13:48 (bapt!~b...@ns3301091.ip-178-32-217.eu) because of sha256 as well efnet / #bsddev / bapt 13:48 (bapt!~b...@ns3301091.ip-178-32-217.eu) well this one could be replaced by libmd but it is way slower efnet / #bsddev / bapt 13:49 (bapt!~b...@ns3301091.ip-178-32-217.eu) also without openssl no https support ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: avoiding base openssl when building ports
On Tue, Jun 02, 2015 at 12:44:46AM +0800, Julian Elischer wrote: 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, You could just call them supported ports. Supported means what currently happens with 3rd party code in base, and unsupported is what software in ports currently is. But, seems like there still would be an issue with compatibility and a stable API or ABI. If the current restrictions are going away, then you might as well just make them ports. If they're staying, you'll end up with an outdated supported port being maintained separately from the current unsupported port, just like now essentially. -- Skip ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
