ports requiring OpenSSL not honouring OpenSSL from ports

[Leif Pedersen]

With respect that there are valid reasons to have port build options, I
kind of hate them. You can't choose them with pkg, and if you pick the
wrong one changing it later is a fragile process, and there's no indication
if a dependency needs options set a particular way.

I'm not bashing the necessary ones, just agonizing against adding more
unless it's *really* necessary.

Are there any ld tricks one could use to make everything use
/usr/local/lib/openssl or /usr/lib/openssl at runtime, system wide,
including base tools? Or are the ABIs different? Then ports could always
build against the base version all the time, and you could switch the whole
system cleanly to the ported version when needed.

It seems to me that picking one or the other per port is never desirable
and means base tools cannot use an upgraded version. Such a strategy would
fix that, if it's possible. But I admit I'm not an ld expert.

Is this strategy possible?
On 2014-04-27 10:52 AM, "Paul Hoffman" <paul.hoffman at vpnc.org> wrote:

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