Re: avoiding base openssl when building ports

[Benjamin Kaduk]

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
> .

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

[Kimmo Paasiala]

On Mon, Jun 1, 2015 at 7:17 PM, Benjamin Kaduk  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
>> .
>
> 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

[Roger Marquis]

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

[Benjamin Kaduk]

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: avoiding base openssl when building ports

[Julian Elischer]

On 6/2/15 12:25 AM, Kimmo Paasiala wrote:

On Mon, Jun 1, 2015 at 7:17 PM, Benjamin Kaduk  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
.

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@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"




___
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"

scope of private libraries

[Benjamin Kaduk]

(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
___
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

[Franco Fichtner]

> On 01 Jun 2015, at 18:42, Benjamin Kaduk  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
___
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

[Benjamin Kaduk]

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

[Walt Ford via freebsd-security]

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"

Re: base/release/10.1.0/contrib/file vulnerabilities?

[Sevan / Venture37]

On 28 April 2015 at 20:48, Mark Felder  wrote:
>
>
> On Mon, Apr 27, 2015, at 03:34, Piotr Kubaj wrote:
>> Hi,
>>
>> I wrote about this vulnerability in January:
>> https://lists.freebsd.org/pipermail/freebsd-security/2015-January/008115.html
>>
>> There were only patches for stable.
>>
>
> There is an open PR as well
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198912


Update from delphij@
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198912#c3

Sevan / Venture37
___
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"