On 2021-11-07 at 06:40:01 UTC-0500 (Sun, 7 Nov 2021 12:40:01 +0100)
Gerben Wierda via macports-users <[email protected]>
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 <[email protected]> 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 Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 1118k 100 1118k 0 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 <[email protected]>
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 affects High Sierra and Mojave. I recommend
upgrading to Catalina or later; I plan to eventually.
Well, you could rebuild MacPorts from source, instructing it to use
a newer copy of libcurl with a newer copy of openssl or libressl
that has a newer certificate bundle. For example, install a
bootstrap copy of MacPorts in a separate prefix, install curl in
that prefix, then rebuild your primary MacPorts from source, telling
it to use the libcurl in the separate prefix. Any future upgrades to
MacPorts base probably also have to be done from source; using "sudo
port selfupdate" will not preserve your configure arguments and
you'll be back to using the System's broken libcurl again.
--
Bill Cole
[email protected] or [email protected]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
