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

[MacPorts]

#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:47 ryandesign]:
 > Replying to [comment:46 neverpanic]:
 > > Replying to [comment:44 ryandesign]:
 > > > 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
 MacPorts.
 >
 > 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.

--
Ticket URL: <https://trac.macports.org/ticket/51516#comment:49>
MacPorts <https://www.macports.org/>
Ports system for macOS