invalid certificate chain during port-fetch

[René J.V. Bertin]

On Friday December 27 2019 21:32:26 Ryan Schmidt wrote:

Hi,

Thanks for looking into this!

>You didn't mention what instructions you're referring to

Only because there are several threads about this issue on S-E and I was on a different machine when I wrote to the ML.. And you must have seen that this is about a "KDE 5" port, i.e. one from my macstrop tree. I didn't draw attention to *that* because the problem has nothing to do with any specific port in particular ;)

>You can use a different method to fetch the file (for example MacPorts curl or Safari or another web browser) and put it in the right place on your system

That's what I did. The curious thing is that my Mac and Linux MacPorts installs both have this patch to portfetch.tcl :

{{{
@@ -567,7 +568,19 @@ proc portfetch::fetchfiles {args} {
                     set fetched 1
                     break
                 } catch {{*} eCode eMessage} {
-                    ui_debug [msgcat::mc "Fetching distfile failed: %s" $eMessage]
+                    ui_warn [msgcat::mc "Fetching distfile failed: %s" $eMessage]
+                    ui_debug "complete command:"
+                    ui_debug "curl fetch {*}$fetch_options $file_url \"${distpath}/${distfile}.TMP\""
+                    if {${eMessage} eq "gnutls_handshake() failed: Handshake failed"} {
+                        if {![catch {system "curl -L $file_url -o \"${distpath}/${distfile}.TMP\""} err]} {
+                            ui_debug [msgcat::mc "Fetching distfile succeeded via curl"]
+                            file rename -force "${distpath}/${distfile}.TMP" "${distpath}/${distfile}"
+                            set fetched 1
+                            break
+                        } else {
+                            ui_warn [msgcat::mc "Fetching distfile failed also via curl: %s" $err]
+                        }
+                    }
                     set lastError $eMessage
                 } finally {
                     file delete -force "${distpath}/${distfile}.TMP"
}}}

IIRC this is a a snippet I restored back in 2016 for reasons long forgotten.

As a result I see this on Linux:

{{{
--->  Fetching distfiles for kf5-libkcontacts
DEBUG: Executing proc-pre-org.macports.fetch-fetch-0
DEBUG: Executing org.macports.fetch (kf5-libkcontacts)
--->  kcontacts-19.08.3.tar.xz does not exist in /opt/local/var/lnxports/distfiles/kf5-libkcontacts
--->  Attempting to fetch kcontacts-19.08.3.tar.xz from https://download.kde.org/stable/applications/19.08.3/src
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
Warning: Fetching distfile failed: gnutls_handshake() failed: Handshake failed
DEBUG: complete command:
DEBUG: curl fetch {*}--progress builtin https://download.kde.org/stable/applications/19.08.3/src/kcontacts-19.08.3.tar.xz "/opt/local/var/lnxports/distfiles/kf5-libkcontacts/kcontacts-19.08.3.tar.xz.TMP"
DEBUG: system: curl -L https://download.kde.org/stable/applications/19.08.3/src/kcontacts-19.08.3.tar.xz -o "/opt/local/var/lnxports/distfiles/kf5-libkcontacts/kcontacts-19.08.3.tar.xz.TMP"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   356  100   356    0     0   1186      0 --:--:-- --:--:-- --:--:--  1186
100  535k  100  535k    0     0   743k      0 --:--:-- --:--:-- --:--:--  743k
DEBUG: Fetching distfile succeeded via curl
DEBUG: Executing proc-post-org.macports.fetch-fetch-0
}}}

but don't understand why the fallback doesn't work on Mac. Maybe a different exception is raised there?

Anyway, I think the fallback makes sense in this kind of situation, and it should handle bootstrap errors gracefully. That is, if port:curl isn't yet installed the system curl will be found.

> We should do our mirroring on a newer version of macOS, but making that change to our server infrastructure is nontrivial.

Heh, is that your way of saying that upgrading the OS isn't as trivial as Apple would like us to believe? :)
I presume SIP is involved here?


>You might want to bring this problem to the attention of whoever runs that server. They may not realize that the restrictions they've put in place impact OS versions as recent as OS X 10.11. They may be willing to relax their restrictions somewhat so that older systems can still connect.

I can try to do that, I have an idea whom I might contact about that. I don't know if they'll care though: the KF5 Frameworks now require Qt 5.12 which no longer supports OS X 10.11 . The last frameworks release that can be made to build on 10.9 (with older versions for the QML-related ones) is 5.60.0 so it's been quiet on that front for me the last 5 months or so :-/

R.