Re: port cannot fetch because of expired cert, but cert is OK according to Safari, curl (question related to Mojave / Catalina)
On Sun, 7 Nov 2021, Bill Cole wrote: So I wonder how widespread this problem is? The problem in this case is not the existence of the cert in the CA bundle, but the fact that this particular expired cert was used in an alternative validation path and the logic of verification for multi-path certs isn't correct. Normally, expired root CAs should stay in there because that allows positive non-verification of certs supposedly issued by an expired (and maybe compromised) root CA. Gotcha; thanks. And I'm not happy with those that are set way in the future; I heard somewhere that 5 years is the recommended max. CAs are special. The current limit on server certs is 397 days. I don't think there's a consensus on CA lifetimes because of the conflicting risks of too-short and too-long lives. One day past a leap year :-) I don't remember where I saw the 5-year recommendation, unfortunately. -- Dave
Re: port cannot fetch because of expired cert, but cert is OK according to Safari, curl (question related to Mojave / Catalina)
On 2021-11-07 at 16:29:30 UTC-0500 (Mon, 8 Nov 2021 08:29:30 +1100 (EST)) Dave Horsfall is rumored to have said: On Sun, 7 Nov 2021, Bill Cole wrote: I have my own Mojave machines working without a problem after removing the bad certificate from /etc/ssl/cert.pem. The one that starts like this: [...] Intrigued, I checked my own: mackie:~ dave$ grep "Not After" /etc/ssl/cert.pem [... many dates snipped ...] So I wonder how widespread this problem is? The problem in this case is not the existence of the cert in the CA bundle, but the fact that this particular expired cert was used in an alternative validation path and the logic of verification for multi-path certs isn't correct. Normally, expired root CAs should stay in there because that allows positive non-verification of certs supposedly issued by an expired (and maybe compromised) root CA. And I'm not happy with those that are set way in the future; I heard somewhere that 5 years is the recommended max. CAs are special. The current limit on server certs is 397 days. I don't think there's a consensus on CA lifetimes because of the conflicting risks of too-short and too-long lives. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: port cannot fetch because of expired cert, but cert is OK according to Safari, curl (question related to Mojave / Catalina)
On Sun, 7 Nov 2021, Bill Cole wrote: I have my own Mojave machines working without a problem after removing the bad certificate from /etc/ssl/cert.pem. The one that starts like this: [...] Intrigued, I checked my own: mackie:~ dave$ grep "Not After" /etc/ssl/cert.pem Not After : Aug 13 23:59:00 2018 GMT Not After : Aug 22 16:41:51 2018 GMT Not After: Aug 22 16:41:51 2018 GMT Not After : Aug 1 23:59:59 2028 GMT Not After : Jan 28 12:00:00 2028 GMT Not After : Dec 15 08:00:00 2021 GMT Not After : Mar 18 10:00:00 2029 GMT Not After : Dec 31 23:59:59 2020 GMT Not After : Dec 31 23:59:59 2020 GMT Not After : Jul 16 23:59:59 2036 GMT Not After : Jul 16 23:59:59 2036 GMT Not After : Jan 18 23:59:59 2038 GMT Not After : Dec 1 23:59:59 2037 GMT Not After : Jul 16 23:59:59 2036 GMT Not After : Sep 17 19:46:36 2036 GMT Not After : Jun 26 00:19:54 2019 GMT Not After : May 25 16:39:40 2019 GMT Not Before: May 25 16:09:40 1999 GMT, Not After: May 25 16:09:40 2019 GMT Not After : Nov 10 00:00:00 2031 GMT Not After : Nov 10 00:00:00 2031 GMT Not After : Nov 10 00:00:00 2031 GMT Not After : Jun 21 04:00:00 2020 GMT Not After : Jun 21 04:00:00 2020 GMT Not After : May 21 04:00:00 2022 GMT Not After : Mar 4 05:00:00 2019 GMT Not After : Jul 16 23:59:59 2036 GMT Not After : Dec 1 23:59:59 2037 GMT Not After : Mar 4 05:00:00 2029 GMT Not After : Mar 4 05:00:00 2029 GMT Not After : Jun 29 17:06:20 2034 GMT Not After : Dec 31 23:59:59 2037 GMT Not After : Jun 29 17:39:16 2034 GMT Not After : Dec 31 23:59:59 2037 GMT Not After : Dec 31 23:59:59 2037 GMT Not After : Dec 31 23:59:01 2039 GMT Not After : Jul 16 23:59:59 2036 GMT Not After : Jan 18 23:59:59 2038 GMT Not After : Dec 1 23:59:59 2037 GMT Not After : May 30 10:48:38 2020 GMT Not After : Dec 31 23:59:59 2028 GMT Not After : Jul 9 18:19:22 2019 GMT Not After : May 12 23:59:00 2025 GMT Not After : Jul 9 23:59:00 2019 GMT Not After : Oct 1 23:59:59 2033 GMT Not After : Oct 1 23:59:59 2033 GMT Not After : Oct 25 08:30:35 2036 GMT Not After : Oct 25 08:36:00 2036 GMT Not After : Oct 25 08:32:46 2036 GMT Not After : Sep 30 14:01:15 2021 GMT Not After : Dec 6 15:08:21 2028 GMT So I wonder how widespread this problem is? And I'm not happy with those that are set way in the future; I heard somewhere that 5 years is the recommended max. -- Dave
Re: port cannot fetch because of expired cert, but cert is OK according to Safari, curl (question related to Mojave / Catalina)
On 2021-11-07 at 06:40:01 UTC-0500 (Sun, 7 Nov 2021 12:40:01 +0100) Gerben Wierda via macports-users is rumored to have said: The reason is libcurl in Mojave which is less permissive than High Sierra. I'm unconvinced of that. I have my own Mojave machines working without a problem after removing the bad certificate from /etc/ssl/cert.pem. The one that starts like this: -### Digital Signature Trust Co. - -=== /O=Digital Signature Trust Co./CN=DST Root CA X3 -Certificate: -Data: -Version: 3 (0x2) -Serial Number: -44:af:b0:80:d6:a3:27:ba:89:30:39:86:2e:f8:40:6b -Signature Algorithm: sha1WithRSAEncryption -Validity -Not Before: Sep 30 21:12:19 2000 GMT -Not After : Sep 30 14:01:15 2021 GMT On 7 Nov 2021, at 03:08, Kastus Shchuka wrote: Something does not add up here. High Sierra is older than Mojave, right? I can fetch sources of nsd on High Sierra without any problems: $ sudo port -d fetch nsd DEBUG: Copying /Users/pike/Library/Preferences/com.apple.dt.Xcode.plist to /opt/local/var/macports/home/Library/Preferences DEBUG: Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/net/nsd DEBUG: OS darwin/17.7.0 (macOS 10.13.6) arch i386 DEBUG: adding the default universal variant DEBUG: Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies DEBUG: Finished running callback portconfigure::add_automatic_compiler_dependencies DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies DEBUG: Finished running callback portbuild::add_automatic_buildsystem_dependencies DEBUG: Running callback portstartupitem::add_notes DEBUG: Finished running callback portstartupitem::add_notes DEBUG: Attempting ln -sf /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_nsd/nsd/work /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/net/nsd/work DEBUG: dropping privileges: euid changed to 504, egid changed to 20. DEBUG: Starting logging for nsd @4.2.1_2 DEBUG: macOS 10.13.6 (darwin/17.7.0) arch i386 DEBUG: MacPorts 2.7.1 DEBUG: Xcode 9.4.1 DEBUG: SDK 10.13 DEBUG: MACOSX_DEPLOYMENT_TARGET: 10.13 DEBUG: Executing org.macports.main (nsd) DEBUG: dropping privileges: euid changed to 504, egid changed to 20. DEBUG: fetch phase started at Sat Nov 6 19:00:42 PDT 2021 ---> Fetching distfiles for nsd DEBUG: elevating privileges for fetch: euid changed to 0, egid changed to 0. DEBUG: dropping privileges: euid changed to 504, egid changed to 20. DEBUG: Executing org.macports.fetch (nsd) ---> nsd-4.2.1.tar.gz does not exist in /opt/local/var/macports/distfiles/nsd ---> Attempting to fetch nsd-4.2.1.tar.gz from http://distfiles.macports.org/nsd % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 1118k 100 1118k0 0 3557k 0 --:--:-- --:--:-- --:--:-- 3563k $ ls -l /opt/local/var/macports/distfiles/nsd total 2240 -rw-r--r-- 1 macports wheel 1145713 Nov 6 19:00 nsd-4.2.1.tar.gz I have MacPorts installed from a package, I did not build it, so it is pretty much standard. Neither I did anything to the system certificate chain. On Nov 6, 2021, at 5:43 AM, Ryan Schmidt wrote: On Nov 6, 2021, at 05:39, Gerben Wierda wrote: I was looking at updating nsd (for which I am maintaining and it is high time) But fetching failed on macOS Mojave (where I have my MacPorts setup). :debug:fetch Executing org.macports.fetch (nsd) :info:fetch ---> nsd-4.3.8.tar.gz does not exist in /opt/local/var/macports/distfiles/nsd :notice:fetch ---> Attempting to fetch nsd-4.3.8.tar.gz from https://www.nlnetlabs.nl/downloads/nsd/ :debug:fetch Fetching distfile failed: SSL certificate problem: certificate has expired Now, my main MacPorts dev/use machine is macOS Mojave so I suspect that is the Mojave-doesn’t-get-root-cert-updates problem. So, I tried to do a port fetch on Catalina, and there it works and the distribution is downloaded. It is strange, though, because Safari on both Catalina (other machine) and Mojave say the cert is fine. Still, it is most likely that this is a problem that comes from still using Mojave. Updating that machine will not happen until late December, so if I am to maintain anything MacPorts, I need a fix to get this working again. I have tried using curl on the Mojave machine, and that one works. So, Safari works, curl works, but port does not work. I tried copying /etc/ssl/cert.pem over to the Mojave machine, but that doesn’t work either. This is the "Let's Encrypt's old root certificate expired" problem described here: https://t
Re: port cannot fetch because of expired cert, but cert is OK according to Safari, curl (question related to Mojave / Catalina)
Actually it was more about curl, using that as a reference point to see if it was behaving differently with certificates based on user. André-John Sent from my phone. Envoyé depuis mon téléphone. > On 07 Nov 2021, at 01:03, Kastus Shchuka wrote: > > > >> On Nov 6, 2021, at 7:53 PM, André-John Mas wrote: >> >> Does it make a difference if you test via sudo or your own user login? >> > > Well, it won't work as regular user. Regular user does not have write > permissions to /opt/local tree. > > On the other hand, it's plain dumb why it works for me. As you can see below, > org.macports.fetch does not use HTTPS, it downloads over HTTP. Certificates > are just irrelevant for that. > > I am not sure what part of macports.conf controls protocol for fetch, I have > not modified that file since 2017. (I guess I should have done it). I looked > at the diff between my macports.conf and macports.conf.default from May 2021, > and I don't see anything with regards to http/https. I must be missing > something there. > > Thanks, > > Kastus > >> André-John >> >> Sent from my phone. Envoyé depuis mon téléphone. >> On 06 Nov 2021, at 22:08, Kastus Shchuka wrote: >>> >>> Something does not add up here. >>> >>> High Sierra is older than Mojave, right? I can fetch sources of nsd on High >>> Sierra without any problems: >>> >>> $ sudo port -d fetch nsd >>> DEBUG: Copying /Users/pike/Library/Preferences/com.apple.dt.Xcode.plist to >>> /opt/local/var/macports/home/Library/Preferences >>> DEBUG: Changing to port directory: >>> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/net/nsd >>> DEBUG: OS darwin/17.7.0 (macOS 10.13.6) arch i386 >>> DEBUG: adding the default universal variant >>> DEBUG: Reading variant descriptions from >>> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf >>> DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies >>> DEBUG: Finished running callback >>> portconfigure::add_automatic_compiler_dependencies >>> DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies >>> DEBUG: Finished running callback >>> portbuild::add_automatic_buildsystem_dependencies >>> DEBUG: Running callback portstartupitem::add_notes >>> DEBUG: Finished running callback portstartupitem::add_notes >>> DEBUG: Attempting ln -sf >>> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_nsd/nsd/work >>> >>> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/net/nsd/work >>> DEBUG: dropping privileges: euid changed to 504, egid changed to 20. >>> DEBUG: Starting logging for nsd @4.2.1_2 >>> DEBUG: macOS 10.13.6 (darwin/17.7.0) arch i386 >>> DEBUG: MacPorts 2.7.1 >>> DEBUG: Xcode 9.4.1 >>> DEBUG: SDK 10.13 >>> DEBUG: MACOSX_DEPLOYMENT_TARGET: 10.13 >>> DEBUG: Executing org.macports.main (nsd) >>> DEBUG: dropping privileges: euid changed to 504, egid changed to 20. >>> DEBUG: fetch phase started at Sat Nov 6 19:00:42 PDT 2021 >>> ---> Fetching distfiles for nsd >>> DEBUG: elevating privileges for fetch: euid changed to 0, egid changed to 0. >>> DEBUG: dropping privileges: euid changed to 504, egid changed to 20. >>> DEBUG: Executing org.macports.fetch (nsd) >>> ---> nsd-4.2.1.tar.gz does not exist in >>> /opt/local/var/macports/distfiles/nsd >>> ---> Attempting to fetch nsd-4.2.1.tar.gz from >>> http://distfiles.macports.org/nsd >>> % Total% Received % Xferd Average Speed TimeTime Time >>> Current >>> Dload Upload Total SpentLeft Speed >>> 100 1118k 100 1118k0 0 3557k 0 --:--:-- --:--:-- --:--:-- >>> 3563k >>> $ ls -l /opt/local/var/macports/distfiles/nsd >>> total 2240 >>> -rw-r--r-- 1 macports wheel 1145713 Nov 6 19:00 nsd-4.2.1.tar.gz >>> >>> I have MacPorts installed from a package, I did not build it, so it is >>> pretty much standard. Neither I did anything to the system certificate >>> chain. >>> On Nov 6, 2021, at 5:43 AM, Ryan Schmidt wrote: > On Nov 6, 2021, at 05:39, Gerben Wierda wrote: > > I was looking at updating nsd (for which I am maintaining and it is high > time) > > But fetching failed on macOS Mojave (where I have my MacPorts setup). > > :debug:fetch Executing org.macports.fetch (nsd) > :info:fetch ---> nsd-4.3.8.tar.gz does not exist in > /opt/local/var/macports/distfiles/nsd > :notice:fetch ---> Attempting to fetch nsd-4.3.8.tar.gz from > https://www.nlnetlabs.nl/downloads/nsd/ > :debug:fetch Fetching distfile failed: SSL certificate problem: > certificate has expired > > Now, my main MacPorts dev/use machine is macOS Mojave so I suspect that > is the Mojave-doesn’t-get-root-cert-updates problem. So, I tried to do a > port fetch on Catal
Re: port cannot fetch because of expired cert, but cert is OK according to Safari, curl (question related to Mojave / Catalina)
On Nov 7, 2021, at 00:03, Kastus Shchuka wrote: > > On the other hand, it's plain dumb why it works for me. As you can see below, > org.macports.fetch does not use HTTPS, it downloads over HTTP. Certificates > are just irrelevant for that. > > I am not sure what part of macports.conf controls protocol for fetch, Right. We already modified MacPorts so that it knows on which OS versions https won't work -- with regard to our mirror servers only. https://github.com/macports/macports-ports/commit/d8986b24bac94f22a60bfdd3e5d815d6a68c7a05
Re: provide latest OS root certificates via port?
> >> it uses the libcurl support compiled into macports base, which >> defaults to using the system curl. To change that you need to rebuild >> base against an updated lib curl. > > Is that something that can be made to happen for all users by the creation > of a new version of something (e.g., tclsh or whatever is linking against > that library)? Having Macports base ship and build against its own copy of curl by default is something that has been discussed previously. I think a fair summary is there is no consensus as to if it is the right thing to do. Chris smime.p7s Description: S/MIME cryptographic signature
Re: port cannot fetch because of expired cert, but cert is OK according to Safari, curl (question related to Mojave / Catalina)
The reason is libcurl in Mojave which is less permissive than High Sierra. Sent from my iPhone > On 7 Nov 2021, at 03:08, Kastus Shchuka wrote: > > Something does not add up here. > > High Sierra is older than Mojave, right? I can fetch sources of nsd on High > Sierra without any problems: > > $ sudo port -d fetch nsd > DEBUG: Copying /Users/pike/Library/Preferences/com.apple.dt.Xcode.plist to > /opt/local/var/macports/home/Library/Preferences > DEBUG: Changing to port directory: > /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/net/nsd > DEBUG: OS darwin/17.7.0 (macOS 10.13.6) arch i386 > DEBUG: adding the default universal variant > DEBUG: Reading variant descriptions from > /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf > DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies > DEBUG: Finished running callback > portconfigure::add_automatic_compiler_dependencies > DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies > DEBUG: Finished running callback > portbuild::add_automatic_buildsystem_dependencies > DEBUG: Running callback portstartupitem::add_notes > DEBUG: Finished running callback portstartupitem::add_notes > DEBUG: Attempting ln -sf > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_nsd/nsd/work > > /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/net/nsd/work > DEBUG: dropping privileges: euid changed to 504, egid changed to 20. > DEBUG: Starting logging for nsd @4.2.1_2 > DEBUG: macOS 10.13.6 (darwin/17.7.0) arch i386 > DEBUG: MacPorts 2.7.1 > DEBUG: Xcode 9.4.1 > DEBUG: SDK 10.13 > DEBUG: MACOSX_DEPLOYMENT_TARGET: 10.13 > DEBUG: Executing org.macports.main (nsd) > DEBUG: dropping privileges: euid changed to 504, egid changed to 20. > DEBUG: fetch phase started at Sat Nov 6 19:00:42 PDT 2021 > ---> Fetching distfiles for nsd > DEBUG: elevating privileges for fetch: euid changed to 0, egid changed to 0. > DEBUG: dropping privileges: euid changed to 504, egid changed to 20. > DEBUG: Executing org.macports.fetch (nsd) > ---> nsd-4.2.1.tar.gz does not exist in /opt/local/var/macports/distfiles/nsd > ---> Attempting to fetch nsd-4.2.1.tar.gz from > http://distfiles.macports.org/nsd > % Total% Received % Xferd Average Speed TimeTime Time Current > Dload Upload Total SpentLeft Speed > 100 1118k 100 1118k0 0 3557k 0 --:--:-- --:--:-- --:--:-- 3563k > $ ls -l /opt/local/var/macports/distfiles/nsd > total 2240 > -rw-r--r-- 1 macports wheel 1145713 Nov 6 19:00 nsd-4.2.1.tar.gz > > I have MacPorts installed from a package, I did not build it, so it is pretty > much standard. Neither I did anything to the system certificate chain. > >> On Nov 6, 2021, at 5:43 AM, Ryan Schmidt wrote: >> >> >> >>> On Nov 6, 2021, at 05:39, Gerben Wierda wrote: >>> >>> I was looking at updating nsd (for which I am maintaining and it is high >>> time) >>> >>> But fetching failed on macOS Mojave (where I have my MacPorts setup). >>> >>> :debug:fetch Executing org.macports.fetch (nsd) >>> :info:fetch ---> nsd-4.3.8.tar.gz does not exist in >>> /opt/local/var/macports/distfiles/nsd >>> :notice:fetch ---> Attempting to fetch nsd-4.3.8.tar.gz from >>> https://www.nlnetlabs.nl/downloads/nsd/ >>> :debug:fetch Fetching distfile failed: SSL certificate problem: certificate >>> has expired >>> >>> Now, my main MacPorts dev/use machine is macOS Mojave so I suspect that is >>> the Mojave-doesn’t-get-root-cert-updates problem. So, I tried to do a port >>> fetch on Catalina, and there it works and the distribution is downloaded. >>> >>> It is strange, though, because Safari on both Catalina (other machine) and >>> Mojave say the cert is fine. Still, it is most likely that this is a >>> problem that comes from still using Mojave. >>> >>> Updating that machine will not happen until late December, so if I am to >>> maintain anything MacPorts, I need a fix to get this working again. >>> >>> I have tried using curl on the Mojave machine, and that one works. >>> >>> So, Safari works, curl works, but port does not work. >>> >>> I tried copying /etc/ssl/cert.pem over to the Mojave machine, but that >>> doesn’t work either. >> >> This is the "Let's Encrypt's old root certificate expired" problem described >> here: >> >> https://trac.macports.org/wiki/ProblemHotlist#letsencrypt >> >> When you said "curl works but port does not work" that's not quite right. >> /opt/local/bin/curl and /opt/local/lib/libcurl.dylib work. /usr/bin/curl and >> /usr/lib/libcurl.dylib (the latter of which MacPorts uses by default) do not >> work for Let's Encrypt-protected sites anymore. >> >> I, on High Sierra, have the same issue, and I have no solution for you. This >> issue affec
