On Sun, May 17, 2015, at 15:50, Roger Marquis wrote:> > You're not understanding the situation: the vulnerability
isn't in
> > OpenSSL; it's a design flaw / weakness in the protocol. This is
why
> > everyone is running like mad from SSL 3.0 and TLS 1.0.
>
> Right, there are two issues being discussed that should be separated.
> The thread was originally about SSL version weaknesses and the rational
> for that (keeping v1.0 around for the near term) was described quite
> well.
>
> The second issue was regarding base and ports versions of openssl and how
> to coordinate between them. I recommended an openssl_base port so that
> security vulnerabilities (not necessarily protocol weaknesses) could be
> more easily remediated (than installworld) and so 'pkg audit' could
> report on those. It was asserted and reasserted that this would be
> infeasible, however, no example or reason was given. Considering the
> time to write and test patches is the same in either case it is still an
> open question.
>
Again, this is not possible. You can't just "replace" the base
OpenSSL.
That port or package would also have to replace every binary and library
in the base system linked to an OpenSSL library such as libcrypt with a
version that was built against the updated OpenSSL. You might as well
fork FreeBSD at this point.
> The problem of multiple versions of the same libraries and binaries,
> however, remains a weakness in the FreeBSD security model. This may be
> one of the reasons why the EU recently recommended more widespread
> adoption of OpenBSD (vs FreeBSD). Either way, it is a design flaw that
> can and should be solved in the most robust way possible.
>
> Roger
OpenBSD can do this because they roll a new release every 6 months. They
don't support an OS release train for 5 years.