scope of private libraries

[Franco Fichtner]

Hi,

the general lack of responses is probably why we have the
OpenSSL base issues and maybe they won’t go away anytime
soon, even though there are no downsides to modularisation.

Yes, anyone can submit patches, but how can potential
contributors from the security domain bring in patches
that elude the scope of the FreeBSD developers.  How can
we reason for better security under such circumstances?
How can a widespread adoption of the diversity trend of
crypto libraries be embraced by FreeBSD without stepping
on anyone’s toes?  How do we actually create the necessary
awareness?  How can we move from labels of “paranoid” to
“secure”?

The last time I tried WITHOUT_CRYPT=1 it was dysfunctional
despite the fact that the flag exists for the purpose of
decoupling base from crypto and being documented without
the notion of having “hiccups”.

And now even one dependency from the ports is what can
prolong said status quo in the face of a constant stream
of upcoming security advisories.

> On 01 Jun 2015, at 20:00, Benjamin Kaduk <kaduk at MIT.EDU> wrote:
> 
> 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.

Thanks for the quick answer from the source, Benjamin.

It is, however, not a good reason why pkgng is dynamically
linked to OpenSSL in base when e.g. sqlite and libucl are
embedded to avoid chicken and egg issues.  Why should OpenSSL
be the exception?  Because it is in base?  Because it is too
big?  Wouldn’t it be easier to embed and deal with security
issues through the ports/packages infrastructure which
basically rocks?

FreeBSD should put effort into getting there, eventually.
That’s all I’m saying.  Where do we start then?


Cheers,
Franco