#58688 closed defect (fixed)
https://distfiles.macports.org requires SNI, but OS X <= 10.8 do not seem to support that
| Reported by: | yan12125 (Chih-Hsuan Yen) | Owned by: | admin@… |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | buildbot/mpbb | Version: | |
| Keywords: | Cc: | ||
| Port: |
Description
https://distfiles.macports.org requires SNI: https://www.ssllabs.com/ssltest/analyze.html?d=distfiles.macports.org&hideResults=on
I believe that's the cause of fetch errors on OS X <= 10.8. Some failure logs:
All of them fail with:
---> Attempting to fetch Python-3.8.0b2.tar.xz from https://distfiles.macports.org/python38-devel
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0DEBUG: Fetching distfile failed: SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
(Fetching from https://www.python.org/ also fails as the latter requires TLS 1.2)
Alternatively, fetching distfiles via HTTP should fix the issue, too.
Change History (9)
comment:1 Changed 5 years ago by neverpanic (Clemens Lang)
comment:2 Changed 5 years ago by yan12125 (Chih-Hsuan Yen)
did you check that?
Nope - I don't have enough disk space to maintain old OS X VMs. SNI is just the first term that came to my head when I saw that error message.
Since distfiles.macports.org is a CDN, there's probably no way to avoid the requirement for SNI.
Maybe the configuration of our CDN changed recently so that it now requires a higher version of TLS than before.
I could also imagine that the root CAs shipped with the respective versions of the OSes have just expired in the meanwhile.
Either case is beyond the control. Maybe the only way to go is using HTTP.
Take a look at https://github.com/macports/macports-ports/blob/master/_resources/port1.0/fetch/mirror_sites.tcl#L503-L507, which decides whether to use TLS or not.
Thank you for the pointer! Opened https://github.com/macports/macports-ports/pull/4772 to workaround that.
comment:3 Changed 5 years ago by yan12125 (Chih-Hsuan Yen)
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:4 follow-up: 5 Changed 5 years ago by ryandesign (Ryan Carsten Schmidt)
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
Please revert.
The private DNS server on the network that the buildbot machines reside on remaps distfiles.macports.org and packages.macports.org to a local server. I forgot to renew the certificates on that server, and they have expired. I just need to renew those certificates to get things working again.
comment:5 follow-up: 7 Changed 5 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to ryandesign:
I just need to renew those certificates to get things working again.
I have renewed the certificates.
Have the builds that failed already been rescheduled?
comment:6 Changed 5 years ago by yan12125 (Chih-Hsuan Yen)
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
comment:7 Changed 5 years ago by yan12125 (Chih-Hsuan Yen)
Replying to ryandesign:
Replying to ryandesign:
I just need to renew those certificates to get things working again.
I have renewed the certificates.
Thank you for the efforts! I've reverted the previous commit.
Have the builds that failed already been rescheduled?
I guess not. I'm not even sure how many builds are affected.
comment:8 Changed 5 years ago by ryandesign (Ryan Carsten Schmidt)
Ok. I'll make a list of ports that were modified between the time the certificate expired and the time of your first commit, and I'll reschedule those builds on the 10.6-10.8 builders.
comment:9 Changed 5 years ago by ryandesign (Ryan Carsten Schmidt)
Well, I didn't do this. I guess I won't get to it anymore.
Since distfiles.macports.org is a CDN, there's probably no way to avoid the requirement for SNI.
Take a look at https://github.com/macports/macports-ports/blob/master/_resources/port1.0/fetch/mirror_sites.tcl#L503-L507, which decides whether to use TLS or not. Maybe the configuration of our CDN changed recently so that it now requires a higher version of TLS than before.
However, I'm not sure whether the issue is actually SNI – did you check that? I could also imagine that the root CAs shipped with the respective versions of the OSes have just expired in the meanwhile.