[MacPorts] #51516: MacPorts should use a bundled copy of a newer libcurl and SSL library rather than the OS X version

MacPorts 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:
      Port:               |

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
 worse place.
 > 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-
 notice/ .
 > 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
 [https://www.ietf.org/mail-archive/web/tls/current/msg25387.html Last
 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>
MacPorts <https://www.macports.org/>
Ports system for macOS

More information about the macports-tickets mailing list