invalid certificate chain during port-fetch

Ryan Schmidt ryandesign at
Sat Dec 28 20:10:29 UTC 2019

On Dec 28, 2019, at 02:57, René J.V. Bertin wrote:

> 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 ;)

I just mentioned it because when you report a problem, it is useful to provide a reproduction recipe and to tell us what you already tried.

>> 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
>  % 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 "/opt/local/var/lnxports/distfiles/kf5-libkcontacts/kcontacts-19.08.3.tar.xz.TMP"
> DEBUG: system: curl -L -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.

I don't want to debug any custom changes you've made to MacPorts base.

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

Not at all. The machine that does the mirroring is an Xserve with a hardware RAID card, and OS X 10.11 is the last version officially to support that machine. I didn't want to risk upgrading to a newer macOS version, since that might cause the RAID to stop working, which would break everything else that that my MacPorts servers do.

I could set up a separate virtual machine running a newer macOS and have it do the fetching and copy the files to the RAID machine. But since most things are fetching just fine from 10.11 I haven't tried to do this yet. I expect to get around to doing this at the same time that I deploy the new buildbot 2 setup but I have no ETA for that.

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

More information about the macports-dev mailing list