#51516: MacPorts should use a bundled copy of a newer libcurl 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 ryandesign@…): Has duplicate #52602. -- Ticket URL: <https://trac.macports.org/ticket/51516#comment:2> MacPorts <https://www.macports.org/> Ports system for the Mac operating system

#51516: MacPorts should use a bundled copy of a newer libcurl 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 raimue@…): The issue is mostly not libcurl itself, but system's libcurl linked against system's OpenSSL 0.9.8, which does not support TLS >= 1.1. Therefore servers that require TLS >= 1.1 can no longer be reached (#51112, #52604). As of OS X 10.9 Mavericks, system's libcurl will use [https://developer.apple.com/reference/security/1654508-secure_transport Secure Transport] instead. Secure Transport supports TLS >= 1.1 as of OS X 10.8 Mountain Lion. If we still wanted to support OS X <= 10.7, we would need both libcurl and a [https://curl.haxx.se/docs/ssl-compared.html compatible SSL/TLS library] in base. -- Ticket URL: <https://trac.macports.org/ticket/51516#comment:4> MacPorts <https://www.macports.org/> Ports system for the Mac operating system

#51516: MacPorts should use a bundled copy of a newer libcurl 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 ryandesign@…): Replying to [comment:3 cal@…]:

I don't think MacPorts should be in the business of distributing a CA bundle. We shouldn't control who our users trust.

I don't care how we arrange it, but MacPorts should at least be able to download from the MacPorts packages and distfiles servers via SSL. If the problem isn't trusting the certificates but rather the capabilities of the SSL library, then we need to bundle a newer SSL library. -- Ticket URL: <https://trac.macports.org/ticket/51516#comment:6> MacPorts <https://www.macports.org/> Ports system for the Mac operating system

#51516: MacPorts should use a bundled copy of a newer libcurl 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 devans@…): I agree that bundling an SSL library could lead to a lot of extra cycles to update the bundle for security issues, etc. Also probably licensing issues with a binary bundle that includes OpenSSL or LibreSSL. Not sure about other SSL libraries. To avoid these issues, could we set it up so a source build could be built with an external library other than the system ones? An interested user could then boot strap from an outdated binary Installer like this: * install old port binary using installer * build the SSL library of your choice using the just installed port binary * do a source build using the installed non-system SSL library using the appropriate configuration parameters ( say `--with-openssl=${prefix}/lib` ) This avoids binary licensing issues and updates for OpenSSL and the like would be handled by the normal port maintenance process. The procedure would need to be well documented to avoid too many "I tried it but it didn't work" tickets. Or is this too complicated for the average user to deal with? Just an idea. -- Ticket URL: <https://trac.macports.org/ticket/51516#comment:8> MacPorts <https://www.macports.org/> Ports system for the Mac operating system

#51516: MacPorts should use a bundled copy of a newer libcurl 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 ryandesign@…): We already downgrade Leopard and earlier to http for packages.macports and distfiles.macports. r150758, r150765. Once we are properly mirroring distfiles before doing buildbot builds, that will probably be a sufficient fix. But it doesn't help old systems download from other sites that require https. -- Ticket URL: <https://trac.macports.org/ticket/51516#comment:10> MacPorts <https://www.macports.org/> Ports system for the Mac operating system

#51516: MacPorts should use a bundled copy of a newer libcurl 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 devans@…): Replying to [comment:11 cal@…]:

The problem with linking against a copy of OpenSSL in `$prefix` is that it will temporarily disappear while OpenSSL itself is upgraded, but that must not interrupt the upgrade process.

Good point.

Replying to [comment:10 ryandesign@…]:

...

Once we are properly mirroring distfiles before doing buildbot builds,

that will probably be a sufficient fix. But it doesn't help old systems download from other sites that require https.

No matter what we do, that's a problem these platforms will always have,

and will continue to do so. As I said, we cannot save abandoned platforms from dying. Agreed. However, we can, perhaps, provide tools for those who are interested in using these platforms regardless of their antiquity. I'm not sure how many such people there are but they're quite enthusiastic and it would be a shame to shun them, altogether, from the MacPorts community. Best world, IMO, would be for them to form an ad hoc interest group within MacPorts so they could cooperatively work on these issues themselves. So I'm suggesting that while we shouldn't commit (and haven't) to supporting officially anything older than 10.9, it wouldn't hurt to add a hook once in a while to allow them to do the work for themselves if they choose to do so. In this case, provide a configuration option for base to optionally build with external libraries rather than system ones to solve the SSL/TLS issues inherent in the old system libraries. By the way, if one wanted to bundle something that is light weight with good protocol coverage and permissive licensing, wolfSSL/CyaSSL looks interesting. curl has supported it upstream as an alternative so openssl/gnutls for a while now. -- Ticket URL: <https://trac.macports.org/ticket/51516#comment:12> MacPorts <https://www.macports.org/> Ports system for the Mac operating system

#51516: MacPorts should use a bundled copy of a newer libcurl 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 ken.cunningham.webuse@…):

Best world, IMO, would be for them to form an ad hoc interest group within MacPorts so they could cooperatively work on these issues themselves.

That might be a good idea. Even for example a separate trac stream for <10.8 issues would keep the main stream uncluttered, give a voice to those trying to keep these machines going, but keep the signal-to-noise ratio up for the main cadre of users. People who wanted to help out with older systems could. I have been working on port repository overlays for my own use that provide workable shadows for no-longer-working ports on Tiger / Leopard / Snowleopard. For example, <https://github.com/ken-cunningham- webuse/TigerPorts>. Other Tiger users would likely find this helpful. Welcome any contribution or input. -- Ticket URL: <https://trac.macports.org/ticket/51516#comment:14> MacPorts <https://www.macports.org/> Ports system for the Mac operating system

#51516: MacPorts should use a bundled copy of a newer libcurl 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 cal@…): Replying to [comment:13 ryandesign@…]:

I don't understand why you would say that. The problem right now is caused by older systems have an old SSL implementation. The proposed fix is to provide a newer SSL implementation in MacPorts. That fixes the problem.

Yes, that fixes the problem ''in MacPorts'', but users on these platforms will continue to experience the same problems with other services that use TLS. So we can't fix the problem completely, but would still bundle an SSL library on platforms that already ship one that's perfectly fine. I agree with devans here, we should provide instructions, warn users about the caveats and have them compile MacPorts against MacPorts curl. -- Ticket URL: <https://trac.macports.org/ticket/51516#comment:16> MacPorts <https://www.macports.org/> Ports system for the Mac operating system