freebsd security - Apr 2014 - ports requiring OpenSSL not honouring OpenSSL from ports

One of the first things I do on installing a new machine is install
OpenSSL from ports. I do build with base OpenSSL due to the many programs
that depend on it, but using ports OpenSSL for ports makes things easier
to patch/update.

In the case of Heartbleed, for example, I was able to fix ports OpenSSL
much sooner than base.

In the process, however, I discovered a couple of ports that built against
base even when the port was installed. I was going to supply patches /
notify the maintainers, but first did a check, and discovered that a lot
of current ports do similar.

It turns out that this wasn't a problem specifically, but more generally,
it's possible that someone may think a port has been patched when it
hasn't.

Basically what I'm asking: Shouldn't a port that uses OpenSSL *always*
build against the port if it's installed?

I realise this isn't always possible to test, especially if the port
Makefile
doesn't have any openSSL configuration options, but I'd like to hear
others opinions on the matter.

[ Not crossposted to ports@ as I'm unsure onbcross-posting etiqurtte, but
  feel free to add them in if appropriate ]

Cheers,
Jamie

-- 
No sig

On Apr 27, 2014, at 8:08 AM, Jamie Landeg-Jones <jamie at
dyslexicfish.net> wrote:
> Basically what I'm asking: Shouldn't a port that uses OpenSSL
*always*
> build against the port if it's installed?
Yes, that is a reasonable expectation. I certainly had it in my head when I
rebuilt Sendmail+TLS after heartbleed, but I didn't think of checking it.
> I realise this isn't always possible to test, especially if the port
Makefile
> doesn't have any openSSL configuration options, but I'd like to
hear
> others opinions on the matter.
It would be good to add such options to as many ports as possible if it can be
done cleanly.

Also, note that this is not bashing on OpenSSL: given their new significant
funding, I would certainly expect the OpenSSL project to be finding-and-fixing
Heartbleed-level bugs repeatedly in the coming years. It is basically impossible
to fix such a bug without bad actors being able to determine and exploit some of
the fixes in unpatched systems.

--Paul Hoffman

On Sun, Apr 27, 2014 at 10:08 AM, Jamie Landeg-Jones
<jamie at dyslexicfish.net> wrote:
> One of the first things I do on installing a new machine is install
> OpenSSL from ports. I do build with base OpenSSL due to the many programs
> that depend on it, but using ports OpenSSL for ports makes things easier
> to patch/update.
>
> In the case of Heartbleed, for example, I was able to fix ports OpenSSL
> much sooner than base.
>
> In the process, however, I discovered a couple of ports that built against
> base even when the port was installed. I was going to supply patches /
> notify the maintainers, but first did a check, and discovered that a lot
> of current ports do similar.
>
> It turns out that this wasn't a problem specifically, but more
generally,
> it's possible that someone may think a port has been patched when it
hasn't.
>
> Basically what I'm asking: Shouldn't a port that uses OpenSSL
*always*
> build against the port if it's installed?
>
The port should use the OpenSSL port if it is installed, unless the
port sets one of these variables in it's Makefile:

WITH_OPENSSL_BASE
USE_OPENSSL_BASE

The port shouldn't be setting these variables.

Do you have a list of which ports used the OpenSSL from base, instead
of the installed OpenSSL port?
Could you check if they set these variables.
> I realise this isn't always possible to test, especially if the port
Makefile
> doesn't have any openSSL configuration options, but I'd like to
hear
> others opinions on the matter.
>
> [ Not crossposted to ports@ as I'm unsure onbcross-posting etiqurtte,
but
>   feel free to add them in if appropriate ]
>
This is more of a ports issue, than a security issue.

Post the list of affected ports to ports@, and/or submit PRs to
correct the them.


-- 
DISCLAIMER:

No electrons were maimed while sending this message. Only slightly bruised.