[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 neverpanic):

 Replying to [comment:47 ryandesign]:
 > 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?

 I do not want to ship a library with potentially known and dangerous
 security vulnerabilities to users. If we use Apple's library and it does
 not work, the blame is on Apple, and users on old OSes cannot expect
 support from Apple. I do not want to create the impression that we support
 this setup.

 Yes, there might be fewer problems, but if there are problems they would
 then be *our* problems. At the moment, they are not.


 > 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?

 The latter, the CA bundle would eventually be too old for new certificates
 to validate.

 > #51045 was merely the first example of a curl bug that's fixed in newer
 versions that I found to link to this ticket. There's another cosmetic
 issue I found on Leopard that's been fixed. I'm sure there have been more
 bugs fixed in curl over the years.

 Do you have specific tickets? I'm not convinced that we should bundle
 every library we use.


 Replying to [comment:48 yan12125]:
 > FWIW, I have a branch that bundles LibreSSL + libcurl with macports-base
 at https://github.com/yan12125/macports-base/tree/bundle-curl.

 Thank you, that's helpful for users that want to run this at their own
 risk.

 Replying to [comment:49 noloader]:
 > 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.

 Early 2000's tools are pretty much not going to give you any reasonable
 assumption of security at this point. I'd rather want users to realize
 that then to give them a false sense of security.


 > 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/ .

 This is not the point of this ticket. Software installed by MacPorts will
 always use modern libraries and support modern crypto. This is about the
 libraries used by MacPorts itself. So either, your `curl` is MacPorts
 curl, which will work, or it is Apple's curl, which we will also not fix
 with this.

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