[MacPorts] #51516: MacPorts should use a bundled copy of a newer libcurl and SSL library rather than the OS X version
noreply at macports.org
Mon Mar 12 13:06:26 UTC 2018
#51516: MacPorts should use a bundled copy of a newer libcurl and SSL library
rather than the OS X version
Reporter: ryandesign | Owner: macports-tickets@…
Type: enhancement | Status: new
Priority: Normal | Milestone: MacPorts Future
Component: base | Version:
Resolution: | Keywords:
Comment (by noloader):
Replying to [comment:49 noloader]:
> > > > Yes, I know that merely using a bundled curl that's still linked
with the system's openssl will not solve all of the problems being
discussed in this ticket. But I think we should still do it because it
will solve some of the problems (e.g. comment:30).
> > >
> > > I think we all agree that we should not bundle an SSL library with
> > I do not agree yet. Older OSes need a newer ssl library to fetch from
some https sites. So can't we provide a newer openssl or libressl on older
systems, and use Apple's Secure Transport on newer ones? Yes there might
be security vulnerabilities discovered in the ssl library we bundle, but
isn't it likely that there are fewer vulnerabilities in it than in the old
openssl version used on those systems?
> > Your objection in comment:3 was that we should not distribute a CA
bundle. Would bundling an ssl library require us to include CA bundle?
Doesn't the OS ship with one that we could use? Or is that part of the
problem—the old OS's CA bundle doesn't contain the information needed to
trust new sites?
> Newer libraries with vulnerabilities seems the lesser of the two evils.
Early 2000's tools with early CA lists don't help with security much.
People will just disable the certificate checks, which puts them in a
> And newer libraries that "just work" seems like a worthy usability and
security goals. People won't have to do things like `wget --no-check-
certificate` and `curl --insecure`.
> Also, those old libraries and programs built on them are going to cause
more trouble in the future because they can't do TLS 1.2. A TLS 1.2-only
configuration is just common place nowadays. For example, GitHub recently
made the engineering change: https://githubengineering.com/crypto-removal-
> After the GitHub change things like `wget --no-check-certificate
--tlsv1` and `curl --insecure --tlsv1` simply will not work. It is
technically impossible for some sites because of the site's configuration.
This is worth mentioning... TLS 1.3 is in Last Call (LC) status on the TLS
WG mailing list. I think the future trend will be sites supporting TLS 1.2
and TLS 1.3 as sites are reconfigured for the new standard. Also see
Call: <draft-ietf-tls-tls13-24.txt> (The Transport Layer Security (TLS)
Protocol Version 1.3) to Proposed Standard].
Without getting too bogged down in what version of `cacert.pem` to use,
maybe the better engineering question would be, how can MacPorts ensure
TLS 1.2 and TLS 1.3 "just work" for users. If you answer that question I
believe the CA list question will follow without much effort.
Ticket URL: <https://trac.macports.org/ticket/51516#comment:50>
Ports system for macOS
More information about the macports-tickets