Re: provide latest OS root certificates via port?

[raf]

On Sun, Oct 31, 2021 at 07:59:29AM -0400, "Richard L. Hamilton" 
 wrote:

> I think you're onto something here. (color highlighting added, not in the 
> original output)
> 
> sh-3.2$ # 10.14
> sh-3.2$ /usr/bin/curl -sS https://ports.macports.org >/dev/null
> curl: (60) SSL certificate problem: certificate has expired
> # lines of advice in error message skipped here
> sh-3.2$ /opt/local/bin/curl -sS https://ports.macports.org >/dev/null
> sh-3.2$ echo $?
> 0
> 
> (the expired above isn't surprising since I haven't updated the root 
> certificates on there)
> 
> but
> 
> sh-3.2$ # 10.6
> sh-3.2$ /usr/bin/curl -sS https://ports.macports.org/ >/dev/null
> curl: (35) error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert 
> protocol version
> sh-3.2$ /opt/local/bin/curl -sS https://ports.macports.org/ >/dev/null
> sh-3.2$ echo $?
> 0
> 
> On the 10.6, I had updated the root certificates...but the error
> is different; evidently there have been changes to the protocol
> and/or crypto used that merely updating the certificates does not
> fix. The MacPorts version of curl still works fine. Note that pointing
> Safari to that same URL (https://ports.macports.org/) also fails with
> unable to establish secure connection. So on older systems, EVEN WITH
> CERTIFICATES UPDATED, browsing with a non-updated browser and/or
> one that uses system libcrypto will fail for various sites, as will
> various non-browser software that tries to establish TLS connections
> using system libcrypto.

I'm fairly sure that Safari on 10.6 only supports
TLSv1.0 which is a separate reason for it not being
able to connect to websites. /usr/bin/curl might have
the same problem. The ports.macports.org does not
support TLSv1.0. If it did, old /usr/bin/curl might
still work.

It uses /usr/lib/libssl.44.dylib. Someone on the
internet thinks that's old LibreSSL, but the first
release that libressl.org admits to is v2.0.0.

> So if mpstats is failing on curl, it's not using the MacPorts version
> of curl. Which certainly would be distorting the stats against the
> poor suffering older OS version users, even if, knowing they're poor
> and suffering, they volunteer to provide stats.
> 
> IMO, it should check if ${prefix}/bin/curl is present and use it if it
> is, and only use the default if that isn't present - which in practice
> probably would never happen, because so many ports ultimately depend
> on the curl port. Interestingly it did NOT matter if PATH began with
> /opt/local/bin when mpstats was run, it still found the OS version
> rather than the MacPorts version.

Yes. I think /opt/local/libexec/macports/lib/macports1.0/diagnose.tcl
is definitely indicating that the system curl is used for some things,
and that must include mpstats. But updates still work.

> > On Oct 31, 2021, at 05:37, raf  wrote:
> > 
> > 
> > Actually, something looks wierd with macports statistics.
> > 
> > On 10.14:
> > 
> >> /opt/local/libexec/mpstats submit
> >  Submitting data to https://ports.macports.org/statistics/submit/ ...
> >  Error: Peer certificate cannot be authenticated with given CA certificates
> >  while executing
> >  "curl post "submission\[data\]=$json" $stats_url"
> > 
> > On 10.6:
> > 
> >> /opt/local/libexec/mpstats submit
> >  Submitting data to https://ports.macports.org/statistics/submit/ ...
> >  Error: SSL connect error
> >  while executing
> >  "curl post "submission\[data\]=$json" $stats_url"
> > 
> > It has a LetsEncrypt certificate but this should work. It should be 
> > macport's
> > curl that has its own CA bundle.
> > 
> > The certificate chain does still contain "DST Root CA X3". I thought that
> > was getting removed.
> > 
> > Anyway, it looks like I didn't manage to fix my system root certificates
> > after all, even though "ISRG Root X1" is installed (and "DST Root XA 3" is
> > manually trusted just to be extra sure). :-)
> > 
> > /usr/bin/curl is still failing, and for some reason, mpstats must be using
> > /usr/bin/curl instead of /opt/local/bin/curl. That doesn't sound possible, 
> > but
> > that's what it looks like.
> > 
> > According to check_for_app in 
> > /opt/local/libexec/macports/lib/macports1.0/diagnose.tcl,
> > it looks like the curl that's used is the system one in /usr/bin.
> > 
> > I think that means that macports does require the system root certificates
> > to be functional (for some things at least). Is anyone else on old systems
> > able to run "/opt/local/libexec/mpstats submit"? I read somewhere that 
> > errors
> > are silently ignored during automatic submission.
> > 
> > Could this be why https://ports.macports.org/statistics/ shows almost 
> > nothing
> > for 10.{14,13,8,7,6,5,4}? Or are those numbers accurate?
> > 
> > cheers,
> > raf
> -- 
> eMail:mailto:rlha...@smart.net

Re: provide latest OS root certificates via port?

[raf]

On Sun, Oct 31, 2021 at 11:46:46AM +0100, Henning Hraban Ramm  
wrote:

> 
> > Am 31.10.2021 um 10:37 schrieb raf :
> > 
> > On Fri, Oct 29, 2021 at 09:02:34AM -0700, Michael  
> > wrote:
> > 
> > And this will happen again and again as every root certificate becomes
> > ancient and expires. So it would be nice to have an easy way to to keep
> > a system's root certificates up to date, and hopefully, one day, operating
> > system vendors will agree. :-) It'll get on the news when everyone's smart
> > TVs stop working. :-)
> 
> These TVs will have stopped working long before their certificates expire. ;)
> Then it’s just a problem for the restaurators in technical museums.
> 
> > But since it seems that there are few people using old macOS systems,
> > it might remain a manual process.
> 
> I guess there are more than few people, but not everyone complains publicly.
> I just silently installed the necessary root cert.
> 
> I’m working on a 2013 Mac mini and can’t upgrade further than 10.14 (don’t 
> want to loose my 32 bit software, and I seem too stupid for VMs).
> (I also just upgraded a 2012 Thinkpad Edge with a SSD and current Ubuntu, but 
> that’s a different story.)
> 
> > Is anyone else on old systems
> > able to run "/opt/local/libexec/mpstats submit"? I read somewhere that 
> > errors
> > are silently ignored during automatic submission.
> 
> It’s not installed. To which port does the command belong?
> 
> Hraban

It's the "mpstats" port.

cheers,
raf

Re: do I have to reinstall my ports after upgrading to Monterey?

[Artemio González López via macports-users]

> On 31 Oct 2021, at 16:46, Christopher Jones  wrote:
> 
> 
> Yes you do. You should always follow the migration instructions under
> 
> https://trac.macports.org/wiki/Migration 
> 
> 
> Chris
> 
>> On 31 Oct 2021, at 3:45 pm, Artemio González López via macports-users 
>> > > wrote:
>> 
>> I just installed macOS 12.0.1 on an M1 MacBook Pro 13” from last year, and I 
>> was wondering if it’s necessary to reinstall all my ports (which I installed 
>> under Big Sur) after the update (they seem to be running just fine).
>> 
>> Thanks a lot in advance,
>> 
>> Artemio
>> 
>> 
>> Artemio Gonzalez Lopez
>> artem...@mac.com 
> 

Hi, Chris,

Thanks a lot for your (almost instantaneous!) answer. I followed your advised 
and proceeded to migrate my MacPorts installation to macOS 12. I first upgraded 
to Xcode 13.1, and downloaded (from the Developer site) and installed the 13.1 
Command Tools, and then followed all the steps in the migration instructions. 
The only non-standard thing I did was to change macports.conf the build_arch to 
arm64 by adding the following line to it:

build_arch  arm64

 However, the last command (sudo ./restore_ports.tcl myports.txt) ended with 
the following error:

--->  Building libgcc11
Error: Failed to build libgcc11: command execution failed
Error: See 
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc11/libgcc11/main.log
 for details.
--->  Computing dependencies for py39-pyqt5
--->  Dependencies to be installed: qt5 qt5-qt3d qt5-qtbase qt5-qtdeclarative 
qt5-qtsvg qt5-qtgamepad qt5-qtimageformats qt5-qtconnectivity 
qt5-qtgraphicaleffects qt5-qtlocation qt5-qtquickcontrols qt5-qtquickcontrols2 
qt5-qtserialport qt5-qtmacextras qt5-qtmultimedia qt5-qtnetworkauth 
qt5-qtremoteobjects qt5-qtscxml qt5-qtsensors qt5-qtserialbus qt5-qtspeech 
qt5-qttools qt5-qttranslations qt5-qtwebchannel qt5-qtwebsockets 
qt5-qtxmlpatterns qt5-sqlite-plugin qt5-qtscript
Warning: The macOS 12 SDK does not appear to be installed. Ports may not build 
correctly.
Warning: You can install it as part of the Xcode Command Line Tools package by 
running `xcode-select --install'.
--->  Fetching archive for qt5-qtbase
--->  Attempting to fetch qt5-qtbase-5.15.2_2+openssl.darwin_21.arm64.tbz2 from 
https://packages.macports.org/qt5-qtbase 

--->  Attempting to fetch qt5-qtbase-5.15.2_2+openssl.darwin_21.arm64.tbz2 from 
https://fra.de.packages.macports.org/qt5-qtbase 

--->  Attempting to fetch qt5-qtbase-5.15.2_2+openssl.darwin_21.arm64.tbz2 from 
https://mse.uk.packages.macports.org/qt5-qtbase 

--->  Configuring qt5-qtbase
Error: Failed to configure qt5-qtbase: configure failure: command execution 
failed
Error: See 
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_aqua_qt5/qt5-qtbase/main.log
 for details.

In fact, going through the command output in the Terminal window I found that 
the first warning about the macOS 12 SDK was here:

--->  Cleaning py39-widgetsnbextension
Warning: The macOS 12 SDK does not appear to be installed. Ports may not build 
correctly.
Warning: You can install it as part of the Xcode Command Line Tools package by 
running `xcode-select --install'.
--->  Computing dependencies for qt5-qtbase

I also found quite a few warnings to the effect that libgcc11 had failed to 
build before the last one.

I’m not sure what to do at this point. In particular:

1. Is there an easy check which ones of my previously installed ports weren’t 
installed?

2. Why was port complaining that the macOS 12 SDK wasn’t installed, if I did 
install the 13.1 command line tools manually (from a package)?

3. Why did libgcc11 failed to build, and how could that be fixed?

3. What should I do to restore my previous installation (i.e., should I start 
from scratch or could I just install the ports that weren’t installed in the 
first run, provided I find out which ones were they)?

Thanks in advance,

Artemio


Artemio Gonzalez Lopez
artem...@mac.com 


smime.p7s
Description: S/MIME cryptographic signature

Re: do I have to reinstall my ports after upgrading to Monterey?

[Christopher Jones]

Yes you do. You should always follow the migration instructions under

https://trac.macports.org/wiki/Migration 


Chris

> On 31 Oct 2021, at 3:45 pm, Artemio González López via macports-users 
>  wrote:
> 
> I just installed macOS 12.0.1 on an M1 MacBook Pro 13” from last year, and I 
> was wondering if it’s necessary to reinstall all my ports (which I installed 
> under Big Sur) after the update (they seem to be running just fine).
> 
> Thanks a lot in advance,
> 
> Artemio
> 
> 
> Artemio Gonzalez Lopez
> artem...@mac.com 



smime.p7s
Description: S/MIME cryptographic signature

do I have to reinstall my ports after upgrading to Monterey?

[Artemio González López via macports-users]

I just installed macOS 12.0.1 on an M1 MacBook Pro 13” from last year, and I 
was wondering if it’s necessary to reinstall all my ports (which I installed 
under Big Sur) after the update (they seem to be running just fine).

Thanks a lot in advance,

Artemio


Artemio Gonzalez Lopez
artem...@mac.com 

Re: provide latest OS root certificates via port?

[Richard L. Hamilton]

https://trac.macports.org/ticket/61333  
is an old ticket about mpstats not reporting on Tiger and Leopard. The problem 
also exists on Snow Leopard (not just certificates there) and as recently as 
Mojave (certificates). The general solution IMO is that mpstats should depend 
on the curl port and always use that version of curl and not the OS version. I 
added a comment to that effect. I don't know how to change the keywords to add 
later OS versions up through Mojave, though.

> On Oct 31, 2021, at 07:59, Richard L. Hamilton  wrote:
> 
> I think you're onto something here. (color highlighting added, not in the 
> original output)
> 
> sh-3.2$ # 10.14
> sh-3.2$ /usr/bin/curl -sS https://ports.macports.org 
>  >/dev/null
> curl: (60) SSL certificate problem: certificate has expired
> # lines of advice in error message skipped here
> sh-3.2$ /opt/local/bin/curl -sS https://ports.macports.org 
>  >/dev/null
> sh-3.2$ echo $?
> 0
> 
> (the expired above isn't surprising since I haven't updated the root 
> certificates on there)
> 
> but
> 
> sh-3.2$ # 10.6
> sh-3.2$ /usr/bin/curl -sS https://ports.macports.org/ 
>  >/dev/null
> curl: (35) error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert 
> protocol version
> sh-3.2$ /opt/local/bin/curl -sS https://ports.macports.org/ 
>  >/dev/null
> sh-3.2$ echo $?
> 0
> 
> On the 10.6, I had updated the root certificates...but the error is 
> different; evidently there have been changes to the protocol and/or crypto 
> used that merely updating the certificates does not fix. The MacPorts version 
> of curl still works fine. Note that  pointing Safari to that same URL 
> (https://ports.macports.org/ ) also fails with 
> unable to establish secure connection. So on older systems, EVEN WITH 
> CERTIFICATES UPDATED, browsing with a non-updated browser and/or one that 
> uses system libcrypto will fail for various sites, as will various 
> non-browser software that tries to establish TLS connections using system 
> libcrypto.
> 
> So if mpstats is failing on curl, it's not using the MacPorts version of 
> curl. Which certainly would be distorting the stats against the poor 
> suffering older OS version users, even if, knowing they're poor and 
> suffering, they volunteer to provide stats.
> 
> IMO, it should check if ${prefix}/bin/curl is present and use it if it is, 
> and only use the default if that isn't present - which in practice probably 
> would never happen, because so many ports ultimately depend on the curl port. 
> Interestingly it did NOT matter if PATH began with /opt/local/bin when 
> mpstats was run, it still found the OS version rather than the MacPorts 
> version.
> 
>> On Oct 31, 2021, at 05:37, raf mailto:macpo...@raf.org>> 
>> wrote:
>> 
>> 
>> Actually, something looks wierd with macports statistics.
>> 
>> On 10.14:
>> 
>>> /opt/local/libexec/mpstats submit
>>  Submitting data to https://ports.macports.org/statistics/submit/ 
>>  ...
>>  Error: Peer certificate cannot be authenticated with given CA certificates
>>  while executing
>>  "curl post "submission\[data\]=$json" $stats_url"
>> 
>> On 10.6:
>> 
>>> /opt/local/libexec/mpstats submit
>>  Submitting data to https://ports.macports.org/statistics/submit/ 
>>  ...
>>  Error: SSL connect error
>>  while executing
>>  "curl post "submission\[data\]=$json" $stats_url"
>> 
>> It has a LetsEncrypt certificate but this should work. It should be macport's
>> curl that has its own CA bundle.
>> 
>> The certificate chain does still contain "DST Root CA X3". I thought that
>> was getting removed.
>> 
>> Anyway, it looks like I didn't manage to fix my system root certificates
>> after all, even though "ISRG Root X1" is installed (and "DST Root XA 3" is
>> manually trusted just to be extra sure). :-)
>> 
>> /usr/bin/curl is still failing, and for some reason, mpstats must be using
>> /usr/bin/curl instead of /opt/local/bin/curl. That doesn't sound possible, 
>> but
>> that's what it looks like.
>> 
>> According to check_for_app in 
>> /opt/local/libexec/macports/lib/macports1.0/diagnose.tcl,
>> it looks like the curl that's used is the system one in /usr/bin.
>> 
>> I think that means that macports does require the system root certificates
>> to be functional (for some things at least). Is anyone else on old systems
>> able to run "/opt/local/libexec/mpstats submit"? I read somewhere that errors
>> are silently ignored during automatic submission.
>> 
>> Could this be why https://ports.macports.org/statistics/ 
>>  shows almost nothing
>> for 10.{14,13,8,7,6,5,4}? Or are those numbers accurate?
>> 
>> cheers,
>> raf
>> 
> 
> -- 
> eMail:mailto:rlha.

Re: provide latest OS root certificates via port?

[Chris Jones]

I have always favoured VMWare over parallels myself, and they now offer a free 
license for non-commerical usages.

https://customerconnect.vmware.com/web/vmware/evalcenter?p=fusion-player-personal

> On 31 Oct 2021, at 12:07 pm, Richard L. Hamilton  wrote:
> 
> Years ago, creating a (then OS X, now macOS) VM under free VirtualBox was a 
> horrid pain (which is why I'm running the relatively expensive but nicer 
> Parallels for that and VMs other than Solaris).
> 
> But apparently now it's relatively easy. You do need plenty of extra disk 
> space and I'd say 8GB more ram than you'd otherwise need. See 
> https://www.soupbowl.io/2020/04/macos-in-virtualbox/
> (I haven't tried it, but it looks believable)
> 
> 
>> On Oct 31, 2021, at 06:46, Henning Hraban Ramm  wrote:
>> 
>> I’m working on a 2013 Mac mini and can’t upgrade further than 10.14 (don’t 
>> want to loose my 32 bit software, and I seem too stupid for VMs).
> 
> 

Re: provide latest OS root certificates via port?

[Richard L. Hamilton]

Years ago, creating a (then OS X, now macOS) VM under free VirtualBox was a 
horrid pain (which is why I'm running the relatively expensive but nicer 
Parallels for that and VMs other than Solaris).

But apparently now it's relatively easy. You do need plenty of extra disk space 
and I'd say 8GB more ram than you'd otherwise need. See 
https://www.soupbowl.io/2020/04/macos-in-virtualbox/
(I haven't tried it, but it looks believable)


> On Oct 31, 2021, at 06:46, Henning Hraban Ramm  wrote:
> 
> I’m working on a 2013 Mac mini and can’t upgrade further than 10.14 (don’t 
> want to loose my 32 bit software, and I seem too stupid for VMs).

Re: provide latest OS root certificates via port?

[Richard L. Hamilton]

I think you're onto something here. (color highlighting added, not in the 
original output)

sh-3.2$ # 10.14
sh-3.2$ /usr/bin/curl -sS https://ports.macports.org >/dev/null
curl: (60) SSL certificate problem: certificate has expired
# lines of advice in error message skipped here
sh-3.2$ /opt/local/bin/curl -sS https://ports.macports.org >/dev/null
sh-3.2$ echo $?
0

(the expired above isn't surprising since I haven't updated the root 
certificates on there)

but

sh-3.2$ # 10.6
sh-3.2$ /usr/bin/curl -sS https://ports.macports.org/ >/dev/null
curl: (35) error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert 
protocol version
sh-3.2$ /opt/local/bin/curl -sS https://ports.macports.org/ >/dev/null
sh-3.2$ echo $?
0

On the 10.6, I had updated the root certificates...but the error is different; 
evidently there have been changes to the protocol and/or crypto used that 
merely updating the certificates does not fix. The MacPorts version of curl 
still works fine. Note that  pointing Safari to that same URL 
(https://ports.macports.org/) also fails with unable to establish secure 
connection. So on older systems, EVEN WITH CERTIFICATES UPDATED, browsing with 
a non-updated browser and/or one that uses system libcrypto will fail for 
various sites, as will various non-browser software that tries to establish TLS 
connections using system libcrypto.

So if mpstats is failing on curl, it's not using the MacPorts version of curl. 
Which certainly would be distorting the stats against the poor suffering older 
OS version users, even if, knowing they're poor and suffering, they volunteer 
to provide stats.

IMO, it should check if ${prefix}/bin/curl is present and use it if it is, and 
only use the default if that isn't present - which in practice probably would 
never happen, because so many ports ultimately depend on the curl port. 
Interestingly it did NOT matter if PATH began with /opt/local/bin when mpstats 
was run, it still found the OS version rather than the MacPorts version.

> On Oct 31, 2021, at 05:37, raf  wrote:
> 
> 
> Actually, something looks wierd with macports statistics.
> 
> On 10.14:
> 
>> /opt/local/libexec/mpstats submit
>  Submitting data to https://ports.macports.org/statistics/submit/ ...
>  Error: Peer certificate cannot be authenticated with given CA certificates
>  while executing
>  "curl post "submission\[data\]=$json" $stats_url"
> 
> On 10.6:
> 
>> /opt/local/libexec/mpstats submit
>  Submitting data to https://ports.macports.org/statistics/submit/ ...
>  Error: SSL connect error
>  while executing
>  "curl post "submission\[data\]=$json" $stats_url"
> 
> It has a LetsEncrypt certificate but this should work. It should be macport's
> curl that has its own CA bundle.
> 
> The certificate chain does still contain "DST Root CA X3". I thought that
> was getting removed.
> 
> Anyway, it looks like I didn't manage to fix my system root certificates
> after all, even though "ISRG Root X1" is installed (and "DST Root XA 3" is
> manually trusted just to be extra sure). :-)
> 
> /usr/bin/curl is still failing, and for some reason, mpstats must be using
> /usr/bin/curl instead of /opt/local/bin/curl. That doesn't sound possible, but
> that's what it looks like.
> 
> According to check_for_app in 
> /opt/local/libexec/macports/lib/macports1.0/diagnose.tcl,
> it looks like the curl that's used is the system one in /usr/bin.
> 
> I think that means that macports does require the system root certificates
> to be functional (for some things at least). Is anyone else on old systems
> able to run "/opt/local/libexec/mpstats submit"? I read somewhere that errors
> are silently ignored during automatic submission.
> 
> Could this be why https://ports.macports.org/statistics/ shows almost nothing
> for 10.{14,13,8,7,6,5,4}? Or are those numbers accurate?
> 
> cheers,
> raf
> 

-- 
eMail:  mailto:rlha...@smart.net

Re: provide latest OS root certificates via port?

[Henning Hraban Ramm]

> Am 31.10.2021 um 10:37 schrieb raf :
> 
> On Fri, Oct 29, 2021 at 09:02:34AM -0700, Michael  wrote:
> 
> And this will happen again and again as every root certificate becomes
> ancient and expires. So it would be nice to have an easy way to to keep
> a system's root certificates up to date, and hopefully, one day, operating
> system vendors will agree. :-) It'll get on the news when everyone's smart
> TVs stop working. :-)

These TVs will have stopped working long before their certificates expire. ;)
Then it’s just a problem for the restaurators in technical museums.

> But since it seems that there are few people using old macOS systems,
> it might remain a manual process.

I guess there are more than few people, but not everyone complains publicly.
I just silently installed the necessary root cert.

I’m working on a 2013 Mac mini and can’t upgrade further than 10.14 (don’t want 
to loose my 32 bit software, and I seem too stupid for VMs).
(I also just upgraded a 2012 Thinkpad Edge with a SSD and current Ubuntu, but 
that’s a different story.)

> Is anyone else on old systems
> able to run "/opt/local/libexec/mpstats submit"? I read somewhere that errors
> are silently ignored during automatic submission.

It’s not installed. To which port does the command belong?


Hraban


signature.asc
Description: Message signed with OpenPGP

Re: provide latest OS root certificates via port?

[raf]

On Fri, Oct 29, 2021 at 09:02:34AM -0700, Michael  wrote:

> As a user who spent a week trying to figure out what was going on
> with more and more sites not working, making less of the information
> out there available to figure out how to solve the expired cert, it
> was really painful to find out that this was "known in advance", and
> worse, this implies that ANY "modern", "secure" OS is an inherent
> time-death, for no good reason.
> 
> Having an easy way to update certs would be wonderful.
> Finding out the hard way that not only did I need to put the DST root
> in, but that in the next year there's a couple more that will expire,
> when this was something that could have, and should have, been made
> very public in advance, was painful.
> 
> Discovering the *harder* way that adding a root key to your personal
> account is not the same as adding it system wide, meaning that the
> first information I got wasn't even accurate, only made things worse
> -- I could browse the web just fine, but stuff running as root from
> launchd was using a different set of certs that did not include this.

Yes, it was a pain. I had similar troubles with a 10.6.8 laptop.
Luckily, I read the LetsEncrypt community forum where it was explained
and various solutions given. They didn't quite work for me but they were
close enough to work something out.

And this will happen again and again as every root certificate becomes
ancient and expires. So it would be nice to have an easy way to to keep
a system's root certificates up to date, and hopefully, one day, operating
system vendors will agree. :-) It'll get on the news when everyone's smart
TVs stop working. :-)

But I agree with Bill that it's not the job of the macports project to do that.
Keeping the ports working on old macOS systems is a huge enough task as it is.
Keeping the OS-provided software itself working is something else.

However, if someone wanted to write a program that keeps a mac's root
certificates up to date, that would be a good port to have. :-)
The keychain can be modified from the command line, so it shouldn't be
too difficult. :-)

But since it seems that there are few people using old macOS systems,
it might remain a manual process.

Actually, something looks wierd with macports statistics.

On 10.14:

  > /opt/local/libexec/mpstats submit
  Submitting data to https://ports.macports.org/statistics/submit/ ...
  Error: Peer certificate cannot be authenticated with given CA certificates
  while executing
  "curl post "submission\[data\]=$json" $stats_url"

On 10.6:

  > /opt/local/libexec/mpstats submit
  Submitting data to https://ports.macports.org/statistics/submit/ ...
  Error: SSL connect error
  while executing
  "curl post "submission\[data\]=$json" $stats_url"

It has a LetsEncrypt certificate but this should work. It should be macport's
curl that has its own CA bundle.

The certificate chain does still contain "DST Root CA X3". I thought that
was getting removed.

Anyway, it looks like I didn't manage to fix my system root certificates
after all, even though "ISRG Root X1" is installed (and "DST Root XA 3" is
manually trusted just to be extra sure). :-)

/usr/bin/curl is still failing, and for some reason, mpstats must be using
/usr/bin/curl instead of /opt/local/bin/curl. That doesn't sound possible, but
that's what it looks like.

According to check_for_app in 
/opt/local/libexec/macports/lib/macports1.0/diagnose.tcl,
it looks like the curl that's used is the system one in /usr/bin.

I think that means that macports does require the system root certificates
to be functional (for some things at least). Is anyone else on old systems
able to run "/opt/local/libexec/mpstats submit"? I read somewhere that errors
are silently ignored during automatic submission.

Could this be why https://ports.macports.org/statistics/ shows almost nothing
for 10.{14,13,8,7,6,5,4}? Or are those numbers accurate?

cheers,
raf