Re: provide latest OS root certificates via port?

[Ryan Schmidt]

> On Nov 11, 2021, at 23:20, raf wrote:
> 
> or using
> the curl binary in the path

Never going to happen. We don't want to maintain two code paths for the same 
purpose.

Re: provide latest OS root certificates via port?

[raf]

On Tue, Nov 09, 2021 at 09:11:26AM -0600, Ryan Schmidt 
 wrote:

> On Nov 7, 2021, at 06:23, Christopher Jones wrote:
> > 
> >>> 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.
> 
> The discussion about that is at https://trac.macports.org/ticket/51516

Thanks. One of the suggestions in that thread was to
default to a non-TLS connection when TLS fails. That
might be an easy option for "mpstats submit", or using
the curl binary in the path, rather than libcurl.
Without something being done to make the default case
work, there will be no statistics for some systems. I
know that having mpstats isn't the default case, but it
is suggested by default.

cheers,
raf

Re: provide latest OS root certificates via port?

[Ryan Schmidt]

On Nov 7, 2021, at 06:23, Christopher Jones wrote:
> 
>>> 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.

The discussion about that is at https://trac.macports.org/ticket/51516

Re: provide latest OS root certificates via port?

[Christopher Jones]

>
>> 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: provide latest OS root certificates via port?

[raf]

On Fri, Nov 05, 2021 at 09:11:25PM -0400, "Richard L. Hamilton" 
 wrote:

> mpstats uses (by default the OS version of) libcurl (which you don't
> want to replace like that!) and not the executable, which is why
> what you tried didn't work (didn't work for me either when I'd tried
> earlier).
> 
> As things stand, one would have to get the MacPorts source (not a
> port!) and build it with an option to use its own version of curl /
> libcurl. Or so someone explained in response to a comment I'd made on
> a ticket about mpstats.

Thanks. It sounds like something that would be best
solved by a new version of MacPorts itself, so as to
solve the problem for all users with old systems.

cheers,
raf

Re: provide latest OS root certificates via port?

[raf]

On Sat, Nov 06, 2021 at 01:09:50AM +, Christopher Jones 
 wrote:

> 
> > 
> > Unfortunately, mpstats submit still doesn't work on 10.6.8,
> > even with /usr/bin/curl replaced with a symlink to
> > /opt/local/bin/curl. I don't understand that.
> > /usr/bin/curl https://ports.macports.org works there with
> > the symlink in place.
> 
> mpstat doesn’t use the command line curl utility, so that change will have no 
> impact on it.

Thanks.

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

> Chris

cheers,
raf

Re: provide latest OS root certificates via port?

[Gerben Wierda via macports-users]

> On 29 Oct 2021, at 17:09, Bill Cole 
>  wrote:
> 
> Yes: Anyone running Mojave or earlier is not exactly skydiving without a 
> parachute, but is doing something close. Perhaps it's akin to skydiving with 
> a homemade parachute…


To be fair: given that Apple does not announce life cycle for older OS 
versions, they simply stop sending out security patches and you only find out 
ofter the fact, people running Mojave are in a slightly different situation.

It only became clear very recently that Apple had in fact stopped supporting 
Mojave because there was no Mojave version of the most recent security patch. 
And while they stop sending out security patches, they do send out updated 
Safari versions for instance, in other words, it is a bit of a mixed message.

G

Re: provide latest OS root certificates via port?

[Richard L. Hamilton]

mpstats uses (by default the OS version of) libcurl (which you don't want to 
replace like that!) and not the executable, which is why what you tried didn't 
work (didn't work for me either when I'd tried earlier).

As things stand, one would have to get the MacPorts source (not a port!) and 
build it with an option to use its own version of curl / libcurl. Or so someone 
explained in response to a comment I'd made on a ticket about mpstats.

> On Nov 5, 2021, at 20:58, raf  wrote:
> 
> On Fri, Nov 05, 2021 at 09:30:28AM -0500, Ryan Schmidt 
>  wrote:
> 
>> On Oct 31, 2021, at 04:37, raf wrote:
>> 
>>> 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"
>> 
>> We need to make a server configuration change. See
>> 
>> https://trac.macports.org/ticket/63809
> 
> Thanks.
> 
> Unfortunately, mpstats submit still doesn't work on 10.6.8,
> even with /usr/bin/curl replaced with a symlink to
> /opt/local/bin/curl. I don't understand that.
> /usr/bin/curl https://ports.macports.org works there with
> the symlink in place.
> 
> cheers,
> raf
> 

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

Re: provide latest OS root certificates via port?

[Christopher Jones]

>
> Unfortunately, mpstats submit still doesn't work on 10.6.8,
> even with /usr/bin/curl replaced with a symlink to
> /opt/local/bin/curl. I don't understand that.
> /usr/bin/curl https://ports.macports.org works there with
> the symlink in place.


mpstat doesn’t use the command line curl utility, so that change will have no 
impact on it.

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.

Chris



smime.p7s
Description: S/MIME cryptographic signature

Re: provide latest OS root certificates via port?

[raf]

On Fri, Nov 05, 2021 at 09:30:28AM -0500, Ryan Schmidt 
 wrote:

> On Oct 31, 2021, at 04:37, raf wrote:
> 
> > 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"
> 
> We need to make a server configuration change. See
> 
> https://trac.macports.org/ticket/63809

Thanks.

Unfortunately, mpstats submit still doesn't work on 10.6.8,
even with /usr/bin/curl replaced with a symlink to
/opt/local/bin/curl. I don't understand that.
/usr/bin/curl https://ports.macports.org works there with
the symlink in place.

cheers,
raf

Re: provide latest OS root certificates via port?

[Ryan Schmidt]

On Oct 31, 2021, at 04:37, raf wrote:

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

We need to make a server configuration change. See

https://trac.macports.org/ticket/63809

Re: provide latest OS root certificates via port?

[Richard L. Hamilton]

I tried that too, and it didn't work for me either. Turns out from a comment on 
that ticket I mentioned previously that mpstats and other MacPorts commands 
(like "port"?) don't use /usr/bin/curl, they have a tcl binding to (by default, 
the system version of) libcurl. So replacing the executable doesn't help. I 
gather one can replace MacPorts (not the ports, but the base installation) with 
a version compiled from source with an option to use its own curl (or actually 
libcurl) rather than the system one Looks like a bit of a nuisance to do; 
apparently there's been long unresolved discussion about whether or not to 
change the default installation to do that, but while I see the upside to the 
change (more stuff works on older systems, and their stats  don't go 
unreported), I haven't seen the downside arguments.

> On Nov 3, 2021, at 00:39, raf  wrote:
> Thanks! That worked on 10.14. I couldn't find the equivalent cert.pem
> file for /usr/bin/curl on 10.6.8 (not that the same thing would have
> worked there anyway), so I did this instead:
> 
>  cd /usr/bin
>  mv curl curl.orig
>  ln -s /opt/local/bin/curl curl
> 
> After that, "/usr/bin/curl https://ports.macports.org; worked
> but "/opt/local/libexec/mpstats submit" still fails
> with the same error.
> 
> cheers,
> raf
> 

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

Re: provide latest OS root certificates via port?

[raf]

On Mon, Nov 01, 2021 at 06:37:08AM -0400, "Richard L. Hamilton" 
 wrote:

> 
> 
> > On Nov 1, 2021, at 03:12, raf  wrote:
> > 
> > On Sat, Oct 30, 2021 at 05:49:11AM -0700, Al Varnell via macports-users 
> >  wrote:
> > 
> >> I see that I already have the latest ISRG Root X1 certificate in the
> >> System Roots keychain, so not sure why I would need to add it to my
> >> System keychain.
> > 
> > It doesn't sound sensible, does it? I followed those instructions,
> > then added it to System Roots because it hadn't changed anything,
> > only to discover (on 10.6) that only TLSv1.0 was supported by the
> > system-supplied software so things wouldn't work anyway.
> > 
> > I still don't understand why /usr/bin/curl isn't working for me on
> > 10.14 but Safari is.
> 
> /usr/bin/curl (also?) uses /etc/ssl/cert.pem file. Copy that file to
> /etc/ssl/cert.pem.orig as a backup and look around line 1130 for the
> following:
> 
> ### 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
> Subject: O=Digital Signature Trust Co., CN=DST Root CA X3
> X509v3 extensions:
> X509v3 Basic Constraints: critical
> CA:TRUE 
> X509v3 Key Usage: critical
> Certificate Sign, CRL Sign 
> X509v3 Subject Key Identifier:
> C4:A7:B1:A4:7B:2C:71:FA:DB:E1:4B:90:75:FF:C4:15:60:85:89:10
> SHA1 Fingerprint=DA:C9:02:4F:54:D8:F6:DF:94:93:5F:B1:73:26:38:CA:6A:D7:7C:13
> SHA256 
> Fingerprint=06:87:26:03:31:A7:24:03:D9:09:F1:05:E6:9B:CF:0D:32:E1:BD:24:93:FF:C6:D9:20:6D:11:BC:D6:77:07:39
> -BEGIN CERTIFICATE-
> 
> 
> Remove from there (if it is line 1130) to the matching
> -END CERTIFICATE-
> line in /etc/ssl/cert.pem (around 1171) and that gets rid of the
> expired X3 cert that doesn't really need to be in the certificate
> chain. After that,
> /opt/local/libexec/mpstats submit
> works for me on 10.14. Still doesn't help with what's presumably the
> TLS problem on older versions (10.6.8 being the only older version I
> have available, so I don't know just what version is the cutoff for
> that problem).

Thanks! That worked on 10.14. I couldn't find the equivalent cert.pem
file for /usr/bin/curl on 10.6.8 (not that the same thing would have
worked there anyway), so I did this instead:

  cd /usr/bin
  mv curl curl.orig
  ln -s /opt/local/bin/curl curl

After that, "/usr/bin/curl https://ports.macports.org; worked
but "/opt/local/libexec/mpstats submit" still fails
with the same error.

cheers,
raf

Re: provide latest OS root certificates via port?

[Richard L. Hamilton]

> On Nov 1, 2021, at 03:12, raf  wrote:
> 
> On Sat, Oct 30, 2021 at 05:49:11AM -0700, Al Varnell via macports-users 
>  wrote:
> 
>> I see that I already have the latest ISRG Root X1 certificate in the
>> System Roots keychain, so not sure why I would need to add it to my
>> System keychain.
> 
> It doesn't sound sensible, does it? I followed those instructions,
> then added it to System Roots because it hadn't changed anything,
> only to discover (on 10.6) that only TLSv1.0 was supported by the
> system-supplied software so things wouldn't work anyway.
> 
> I still don't understand why /usr/bin/curl isn't working for me on
> 10.14 but Safari is.

/usr/bin/curl (also?) uses /etc/ssl/cert.pem file. Copy that file to 
/etc/ssl/cert.pem.orig as a backup and look around line 1130 for the following:

### 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
Subject: O=Digital Signature Trust Co., CN=DST Root CA X3
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE 
X509v3 Key Usage: critical
Certificate Sign, CRL Sign 
X509v3 Subject Key Identifier:
C4:A7:B1:A4:7B:2C:71:FA:DB:E1:4B:90:75:FF:C4:15:60:85:89:10
SHA1 Fingerprint=DA:C9:02:4F:54:D8:F6:DF:94:93:5F:B1:73:26:38:CA:6A:D7:7C:13
SHA256 
Fingerprint=06:87:26:03:31:A7:24:03:D9:09:F1:05:E6:9B:CF:0D:32:E1:BD:24:93:FF:C6:D9:20:6D:11:BC:D6:77:07:39
-BEGIN CERTIFICATE-


Remove from there (if it is line 1130) to the matching
-END CERTIFICATE-
line in /etc/ssl/cert.pem (around 1171) and that gets rid of the expired X3 
cert that doesn't really need to be in the certificate chain. After that,
/opt/local/libexec/mpstats submit
works for me on 10.14. Still doesn't help with what's presumably the TLS 
problem on older versions (10.6.8 being the only older version I have 
available, so I don't know just what version is the cutoff for that problem).

Re: provide latest OS root certificates via port?

[Al Varnell via macports-users]

Sent from my iPad

On Nov 1, 2021, at 00:12, raf  wrote:
>> And when I went to https://letsencrypt.org/certs/isrgrootx1.pem
>> to download, it showed up as a .cer instead of a .pem.
>> 
>> -Al-
> 
> That file is in PEM format.
> Is it just the filename suffix that is of concern, or the format?

Yes, I would expect a direct link to download a file would download a file with 
that exact file name, including suffix.

> i.e. does it start with "-BEGIN CERTIFICATE-"?
> If so, it can be renamed to isrgrootx1.pem (but it might not matter).

No, it's name was isrgrootx1.cer

> cheers,
> raf

I really have no need for it since the fully up-to-date certificate was already 
installed on my Mac. Just pointing that out along with the strangeness with the 
suffix.

-Al-

Re: provide latest OS root certificates via port?

[raf]

On Mon, Nov 01, 2021 at 08:13:14AM +0100, Henning Hraban Ramm  
wrote:

> 
> > Am 01.11.2021 um 00:32 schrieb raf :
> > 
> > On Sun, Oct 31, 2021 at 11:46:46AM +0100, 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).
> >> (I also just upgraded a 2010 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?
> > 
> > It's the "mpstats" port.
> 
> I could have guessed. Actually I tried "port search", and nothing turned up – 
> today it did. Probably I mistyped.
> 
> $ /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"
> 
> So I can confirm the issue on 10.4, even after installing the ISRG Root 
> certificate in the System keychain.
> 
> Sláinte,
> Hraban

I would have thought it would be a TLS version problem,
rather than, a certificate problem, but it does mention
the certificates.

cheers,
raf

Re: provide latest OS root certificates via port?

[Henning Hraban Ramm]

> Am 01.11.2021 um 00:32 schrieb raf :
> 
> On Sun, Oct 31, 2021 at 11:46:46AM +0100, 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).
>> (I also just upgraded a 2010 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?
> 
> It's the "mpstats" port.

I could have guessed. Actually I tried "port search", and nothing turned up – 
today it did. Probably I mistyped.

$ /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"

So I can confirm the issue on 10.4, even after installing the ISRG Root 
certificate in the System keychain.

Sláinte,
Hraban


signature.asc
Description: Message signed with OpenPGP

Re: provide latest OS root certificates via port?

[raf]

On Sat, Oct 30, 2021 at 05:49:11AM -0700, Al Varnell via macports-users 
 wrote:

> I see that I already have the latest ISRG Root X1 certificate in the
> System Roots keychain, so not sure why I would need to add it to my
> System keychain.

It doesn't sound sensible, does it? I followed those instructions,
then added it to System Roots because it hadn't changed anything,
only to discover (on 10.6) that only TLSv1.0 was supported by the
system-supplied software so things wouldn't work anyway.

I still don't understand why /usr/bin/curl isn't working for me on
10.14 but Safari is.

> And when I went to https://letsencrypt.org/certs/isrgrootx1.pem
> to download, it showed up as a .cer instead of a .pem.
> 
> -Al-

That file is in PEM format.
Is it just the filename suffix that is of concern, or the format?
i.e. does it start with "-BEGIN CERTIFICATE-"?
If so, it can be renamed to isrgrootx1.pem (but it might not matter).

If you have a binary file in DER format, it can be converted to PEM format:

  openssl x509 -inform der -outform pem -in file.der -out file.pem

Or just download the PEM version. They have both available.

cheers,
raf

> > On Oct 29, 2021, at 10:25 PM, Michael  > > wrote:
> > 
> > So I found this advice online for updating certs without having to worry 
> > about trusting expired old certs.
> > 
> > 1. Visit https://letsencrypt.org/certs/isrgrootx1.pem to download the 
> > certificate, and save it in the Documents folder.
> > 
> > 2. Open Terminal, paste this command, and press enter:
> > 
> > sudo security -v add-trusted-cert -d -r trustRoot -k 
> > "/Library/Keychains/System.keychain" ~/Documents/isrgrootx1.pem
> > 
> > This eliminates the need for marking the expired DST root as special-case 
> > trusted.
> 

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

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

Re: provide latest OS root certificates via port?

[xgfvc via macports-users]

hi all,

as much as i appreciate every discussion, i would kindly ask everybody to 
refrain from posting links pointing at actual downloads
my 0.02$

x

> On 30 Oct 2021, at 2:49 PM, Al Varnell via macports-users 
>  wrote:
> 
> I see that I already have the latest ISRG Root X1 certificate in the System 
> Roots keychain, so not sure why I would need to add it to my System keychain.
> 
> And when I went to https://letsencrypt.org/certs/isrgrootx1.pem 
>  to download, it showed up as a 
> .cer instead of a .pem.
> 
> -Al-
> 
>> On Oct 29, 2021, at 10:25 PM, Michael > > wrote:
>> 
>> So I found this advice online for updating certs without having to worry 
>> about trusting expired old certs.
>> 
>> 1. Visit https://letsencrypt.org/certs/isrgrootx1.pem 
>>  to download the certificate, 
>> and save it in the Documents folder.
>> 
>> 2. Open Terminal, paste this command, and press enter:
>> 
>> sudo security -v add-trusted-cert -d -r trustRoot -k 
>> "/Library/Keychains/System.keychain" ~/Documents/isrgrootx1.pem
>> 
>> This eliminates the need for marking the expired DST root as special-case 
>> trusted.
> 
>  
> Powered by Mailbutler 
> ,
>  the email extension that does it all

Re: provide latest OS root certificates via port?

[Al Varnell via macports-users]

I see that I already have the latest ISRG Root X1 certificate in the System 
Roots keychain, so not sure why I would need to add it to my System keychain.

And when I went to https://letsencrypt.org/certs/isrgrootx1.pem 
 to download, it showed up as a 
.cer instead of a .pem.

-Al-

> On Oct 29, 2021, at 10:25 PM, Michael  > wrote:
> 
> So I found this advice online for updating certs without having to worry 
> about trusting expired old certs.
> 
> 1. Visit https://letsencrypt.org/certs/isrgrootx1.pem 
>  to download the certificate, 
> and save it in the Documents folder.
> 
> 2. Open Terminal, paste this command, and press enter:
> 
> sudo security -v add-trusted-cert -d -r trustRoot -k 
> "/Library/Keychains/System.keychain" ~/Documents/isrgrootx1.pem
> 
> This eliminates the need for marking the expired DST root as special-case 
> trusted.

 
Powered by Mailbutler 
,
 the email extension that does it all

smime.p7s
Description: S/MIME cryptographic signature

Re: provide latest OS root certificates via port?

[Michael]

So I found this advice online for updating certs without having to worry about 
trusting expired old certs.

1. Visit https://letsencrypt.org/certs/isrgrootx1.pem to download the 
certificate, and save it in the Documents folder.

2. Open Terminal, paste this command, and press enter:

sudo security -v add-trusted-cert -d -r trustRoot -k 
"/Library/Keychains/System.keychain" ~/Documents/isrgrootx1.pem

This eliminates the need for marking the expired DST root as special-case 
trusted.

Re: provide latest OS root certificates via port?

[Steven Smith]

> ANY "modern", "secure" OS is an inherent time-death, for no good reason.

Yes they are, but for good reasons. 

People discover vulnerabilities and patch them. Unpatched systems are 
vulnerable. This happens for all sorts of technical issues, especially PKI. For 
example,

Analysis of SSL Certificate Reissues and Revocations in the Wake of Heartbleed
https://dl.acm.org/doi/pdf/10.1145/3176244

Trusting old PKI is a Bad Idea.

Re: provide latest OS root certificates via port?

[James]

> On 30 Oct 2021, at 12:02 am, Richard L. Hamilton  wrote:
> 
> I have VMs of a couple of old macOS / OS X versions, because I want continued 
> access to the features that have been removed in more recent versions (32-bit 
> user land support in Mojave, ability to run PowerPC apps and executables in 
> Snow Leopard).
> 
> But the old machine that ran Snow Leopard is pretty much dead (why I built a 
> Snow Leopard VM with all its apps copied over to replace it before it died 
> completely). So everything runs on newer systems, but I can still run the old 
> OS versions as VMs if I need them.
> 
> One might of course need more $$ to obtain a newer system (although one can 
> probably scrounge a deal on a newer enough used one, if one is careful).
> 
> So I'm not sure what the limitation would be to ONLY using an old system - 
> although if businesses or bureaucrats are involved, limitations may not be 
> sensible.

What VMs do you use. I find VBox unusable Parallels works nicely, but John 
Hoyt, doing stuff for mythtv found VBox to be ok..

James

Re: provide latest OS root certificates via port?

[Dave Horsfall]

On Fri, 29 Oct 2021, Bill Cole wrote:

Yes: Anyone running Mojave or earlier is not exactly skydiving without a 
parachute, but is doing something close. Perhaps it's akin to skydiving 
with a homemade parachute...


Well, my ancient MacBook Pro is stuck on High Sierra; then again I'm 
careful about the sites that I visit and have all sorts of add-ons, and 
the Mac itself is not accessible from the 'Net.


-- Dave

Re: provide latest OS root certificates via port?

[Christopher Jones]

> On 29 Oct 2021, at 4:17 pm, Richard Bonomo TDS personal  
> wrote:
> 
> 
> I don't know what to think about MacPorts, specifically, providing
> new certificates, but, pertaining to some of the arguments presented
> against doing this on old Macs generally, it must be kept in mind
> that some of us -- including yours truly -- have Apple computers that
> CANNOT use newer operating systems or browsers.  Sometimes, one has
> to work with what one has.

There are other OSes, linux distros for instance, designed for such scenarios..

> 
> Rich
> 
> - Original Message -
> From: "Bill Cole" 
> To: "macports-users Users" 
> Sent: Friday, October 29, 2021 10:09:45 AM
> Subject: Re: provide latest OS root certificates via port?
> 
> On 2021-10-29 at 07:23:38 UTC-0400 (Fri, 29 Oct 2021 07:23:38 -0400)
> Richard L. Hamilton 
> is rumored to have said:
> 
>> You're (probably - seems plausible but I haven't verified it myself) 
>> right that that's annoying and fixable.
>> 
>> But there's a big reason to think carefully about whether to do that. 
>> If something is old enough that it isn't receiving certificate 
>> updates, it probably isn't receiving security updates either. And the 
>> same applications and functionality that need current root 
>> certificates to work are also likely to be common attack points.
>> 
>> So at the very least, anything that makes it easier to take such a 
>> risk should come with a prominent warning, IMO.
> 
> Yes: Anyone running Mojave or earlier is not exactly skydiving without a 
> parachute, but is doing something close. Perhaps it's akin to skydiving 
> with a homemade parachute...
> 
> Frankly, I don't think MacPorts should attempt to 'fix' this issue or 
> similar future issues diretly, not because it encourages risky behavior 
> but because MacPorts should avoid poking around in the MacOS base at all 
> where it isn't essential for the operation of MacPorts. It's easy enough 
> in principle for MacPorts to stand up and use its own modern OSS-based 
> encryption+PKI stack with its own set of trusted CAs (e.g. 
> curl-ca-bundle and openssl ports) and so keep itself functional without 
> poking around in core functionality of the OS that MacPorts-naive tools 
> need to use. People who need to fix the problem of an expired root cert 
> should be able to understand and repair that problem (which can be done 
> without digging a CA bundle out of a newer system) if they need to, and 
> having the issue unaddressed is not itself a security issue, but a 
> functionality issue. Anyone who actually wants to run Safari & Chrome on 
> an OS that isn't getting basic security maintenance should be thinking 
> very carefully about what they are doing and accept responsibility for 
> making something work which arguably should no longer work because it is 
> too risky.
> 
> One risk for MacPorts is a slippery slope created by providing support 
> for antique OS versions that include opaque proprietary bits that are 
> probably insecure in ways that no one fully understands. If it is taken 
> too far (which in my opinion includes fixing core components like PKI) 
> MP would be doing a disservice to users who understandably expect a 
> "Just Works" experience on a Mac by enabling the continued use of tools 
> that could well have permanent unrecognized and mostly invisible 
> security flaws.
> 
> 
>>> On Oct 29, 2021, at 07:12, René J.V. Bertin  
>>> wrote:
>>> 
>>> Hi,
>>> 
>>> Users of older Apple OSes that are no longer receiving updates 
>>> probably noticed that Safari and Chrome-based browsers no longer 
>>> connect to lots of sites because a crucial root certificate has 
>>> expired.
>>> 
>>> Answer 1 to 
>>> https://apple.stackexchange.com/questions/422332/how-do-i-update-my-root-certificates-on-an-older-version-of-mac-os-e-g-el-capi
>>>  
>>> provides an easy solution, but you need access to an up-to-date OS 
>>> install.
>>> 
>>> These are not proprietary to Apple so I presume it should be possible 
>>> to provide the suggested `rootcerts.pem` file via a port - possibly 
>>> even install it in the post-activate. I had a look but couldn't find 
>>> if such a port already exists. I think it'd help for lots of 
>>> people... I'd propose a draft but I'm running 10.9 ... so thanks to 
>>> anyone picking this up!
>>> 
>>> R.
>>> 
> 
> 
> -- 
> Bill Cole
> b...@scconsult.com or billc...@apache.org
> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
> Not Currently Available For Hire



smime.p7s
Description: S/MIME cryptographic signature

Re: provide latest OS root certificates via port?

[Richard L. Hamilton]

Neither does Osborne Computer Corporation. :-) But that's a hobby, and doesn't 
have connectivity issues anyway. But I don't run the browser on my Sun 
workstation, either (an ancient version of Firefox, I think; I may still have 
Mosaic on there, but that's so old it's just plain useless).

FWIW, I find a refurbished late 2014 Mac Mini (oldest low-end Mac that can run 
Monterey) at OWC for as little as $189 (doubtless a low end config, but likely 
competitive with something even older). That's not even the lowest possible 
price, just the low end of what I saw in 10 seconds looking at search results, 
from a reputable seller. More looking could beat that. Heck, someone here may 
have something non-ancient (at least able to run Catalina, which still gets 
security updates) they'd be willing to part with for the cost of shipping. 
Alas, not me; I'm the graveyard of old computers, as that Osborne (and an even 
older Exidy Sorcerer) might suggest.

Is there a modern GUI browser in MacPorts, that uses only libs supplied by 
MacPorts (aside from libSystem)? If so, using that might be kinda sorta safer 
than using Safari on a system with no current security updates.

> On Oct 29, 2021, at 12:45, Richard Bonomo TDS personal  wrote:
> 
> 
> Well, some of us are reasonably competent in managing risk, but cannot afford 
> to be buying new computers.
> So the Apples I have, or are on loan to me, have to be kept going.
> 
> On a more pathologic level, I am also in possession (extended load) of a µVAX 
> workstation that I should try
> to get working again.  There is no such thing as a support contract for that, 
> and DEC does not exist any more.
> 
> Rich
> 
> - Original Message -
> From: "Richard L. Hamilton" 
> To: "macports-users Users" 
> Sent: Friday, October 29, 2021 11:25:56 AM
> Subject: Re: provide latest OS root certificates via port?
> 
> 
> 
>> On Oct 29, 2021, at 12:02, 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.
>> 
>> Some sort of "Warning! This system is considered extremely vulnerable" is 
>> fine. But we see ATM's running windows XP, voting machines running Vista, 
>> etc. Old systems being used past their expiration date is normal.
> 
> The ancient (and inadequately audited and reviewed, even if not ancient) 
> software on ATMs and voting machines should be a scandal. Although they are 
> (supposedly) more physically controlled than user desktops/laptops are, and 
> are at least INTENDED to be limited to specific kiosk-like functions and 
> nothing else, so they're FAR less exposed (software-wise) than a browser 
> accessing potentially anything, including once-legit sites that had been 
> hacked to become nasty.  The risks are (IMO) NOT THE SAME.
> 
>> Or do you think that 50 year old FORTRAN programs on 370 systems should be 
>> retired and the entire financial system forced to rewrite code used all 
>> around the world?
> 
> A heck of a lot had to be fixed for Y2K, and some things that couldn't be 
> fixed were either replaced or tossed (including a few that were tossed simply 
> because nobody would take responsibility to affirm that they didn't use 
> dates, even though it was obvious). Been there, done that. It was only a big 
> yawn-fest due to a LOT of hard work. Same thing will happen again in 2038 for 
> any 32-bit Unix/Linux code, btw. That won't be modern desktops (just about 
> all of which are already 64-bit, some now 64-bit only), but a heck of a lot 
> of embedded devices may still be running that old code then. Fortunately I'm 
> retired, so assuming I'm still around, I won't have to deal with THAT me

Re: provide latest OS root certificates via port?

[Giacomo Tufano]

TBH, there is no need to download the entire package of root certs from a new 
version of macOS. Installing the updated root certificate you need should be 
enough. For the case of the expired intermediate certificate of Letsencrypt 
(that causes most of the problems in my personal experience) installing the 
root certificate for ISRG X1 in the keychain from the CA itself should fix the 
problem without creating new packages (and maintaining them). In the case of 
Letencrypt, from this page https://letsencrypt.org/certificates/ 
<https://letsencrypt.org/certificates/> you need to install 
https://letsencrypt.org/certs/isrgrootx1.pem 
<https://letsencrypt.org/certs/isrgrootx1.pem> to fix the problem with 
Letsencrypt “expired” certificates (this works even on old iOS versions). This 
is just a stopgap for what I think it’s the more critical problem now.
Of course: ymmv, just a quick note, you should not install root certificates 
when a stranger tell you to do so from a link on the Internet, etc. etc.

Ciao,
gt


> Il giorno 29 ott 2021, alle ore 18:45, Richard Bonomo TDS personal 
>  ha scritto:
> 
> 
> Well, some of us are reasonably competent in managing risk, but cannot afford 
> to be buying new computers.
> So the Apples I have, or are on loan to me, have to be kept going.
> 
> On a more pathologic level, I am also in possession (extended load) of a µVAX 
> workstation that I should try
> to get working again.  There is no such thing as a support contract for that, 
> and DEC does not exist any more.
> 
> Rich
> 
> - Original Message -
> From: "Richard L. Hamilton" 
> To: "macports-users Users" 
> Sent: Friday, October 29, 2021 11:25:56 AM
> Subject: Re: provide latest OS root certificates via port?
> 
> 
> 
>> On Oct 29, 2021, at 12:02, 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.
>> 
>> Some sort of "Warning! This system is considered extremely vulnerable" is 
>> fine. But we see ATM's running windows XP, voting machines running Vista, 
>> etc. Old systems being used past their expiration date is normal.
> 
> The ancient (and inadequately audited and reviewed, even if not ancient) 
> software on ATMs and voting machines should be a scandal. Although they are 
> (supposedly) more physically controlled than user desktops/laptops are, and 
> are at least INTENDED to be limited to specific kiosk-like functions and 
> nothing else, so they're FAR less exposed (software-wise) than a browser 
> accessing potentially anything, including once-legit sites that had been 
> hacked to become nasty.  The risks are (IMO) NOT THE SAME.
> 
>> Or do you think that 50 year old FORTRAN programs on 370 systems should be 
>> retired and the entire financial system forced to rewrite code used all 
>> around the world?
> 
> A heck of a lot had to be fixed for Y2K, and some things that couldn't be 
> fixed were either replaced or tossed (including a few that were tossed simply 
> because nobody would take responsibility to affirm that they didn't use 
> dates, even though it was obvious). Been there, done that. It was only a big 
> yawn-fest due to a LOT of hard work. Same thing will happen again in 2038 for 
> any 32-bit Unix/Linux code, btw. That won't be modern desktops (just about 
> all of which are already 64-bit, some now 64-bit only), but a heck of a lot 
> of embedded devices may still be running that old code then. Fortunately I'm 
> retired, so assuming I'm still around, I won't have to deal with THAT mess.
> 
>>> Sometimes, one has to work with what one has.
>> 
>> Exactly.
> 
> O

Re: provide latest OS root certificates via port?

[Richard Bonomo TDS personal]

Well, some of us are reasonably competent in managing risk, but cannot afford 
to be buying new computers.
So the Apples I have, or are on loan to me, have to be kept going.

On a more pathologic level, I am also in possession (extended load) of a µVAX 
workstation that I should try
to get working again.  There is no such thing as a support contract for that, 
and DEC does not exist any more.

Rich

- Original Message -
From: "Richard L. Hamilton" 
To: "macports-users Users" 
Sent: Friday, October 29, 2021 11:25:56 AM
Subject: Re: provide latest OS root certificates via port?



> On Oct 29, 2021, at 12:02, 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.
> 
> Some sort of "Warning! This system is considered extremely vulnerable" is 
> fine. But we see ATM's running windows XP, voting machines running Vista, 
> etc. Old systems being used past their expiration date is normal.

The ancient (and inadequately audited and reviewed, even if not ancient) 
software on ATMs and voting machines should be a scandal. Although they are 
(supposedly) more physically controlled than user desktops/laptops are, and are 
at least INTENDED to be limited to specific kiosk-like functions and nothing 
else, so they're FAR less exposed (software-wise) than a browser accessing 
potentially anything, including once-legit sites that had been hacked to become 
nasty.  The risks are (IMO) NOT THE SAME.

> Or do you think that 50 year old FORTRAN programs on 370 systems should be 
> retired and the entire financial system forced to rewrite code used all 
> around the world?

A heck of a lot had to be fixed for Y2K, and some things that couldn't be fixed 
were either replaced or tossed (including a few that were tossed simply because 
nobody would take responsibility to affirm that they didn't use dates, even 
though it was obvious). Been there, done that. It was only a big yawn-fest due 
to a LOT of hard work. Same thing will happen again in 2038 for any 32-bit 
Unix/Linux code, btw. That won't be modern desktops (just about all of which 
are already 64-bit, some now 64-bit only), but a heck of a lot of embedded 
devices may still be running that old code then. Fortunately I'm retired, so 
assuming I'm still around, I won't have to deal with THAT mess.

>> Sometimes, one has to work with what one has.
> 
> Exactly.

Ok, sometimes. In a retro computing museum. Or in a nonprofit with no budget. 
But for anything serious, one REALLY should be aware of the risks, even if that 
means going back to pen, paper, and snail mail rather than taking the risks. Or 
else realizing that EVERYTHING they do where the information or transaction has 
any value at all, is at greater risk of being corrupted or exploited by 
hostiles if they're doing it on that old system, at least if that system has 
Internet access.

But basically EVERY computer, even if the physical box could last longer, has 
support issues past 5 years old, CERTAINLY if one doesn't have a paid support 
contract. I have a box that's industrial enough that it's 20+ years old and has 
only had a drive or two (mirrored, so never any data loss) replaced, but I 
can't (ok, won't) afford a support contract for it (there probably is still 
support for an older OS version that could still run on it, those things were 
built like tanks!), so I know I'm taking my chances. In other words, no system 
seller is going to be on the hook to support an old system forever as part of 
the purchase price; if they'll provide extended support at all, you'd better 
expect to pay extra for that, every year. EVERYTHING costs, 'cause everybody 
has to make a living, including the rich people and the little people at the 
rich people's companies. Magic no problems forever does NOT exist.

Re: provide latest OS root certificates via port?

[Richard L. Hamilton]

> On Oct 29, 2021, at 12:02, 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.
> 
> Some sort of "Warning! This system is considered extremely vulnerable" is 
> fine. But we see ATM's running windows XP, voting machines running Vista, 
> etc. Old systems being used past their expiration date is normal.

The ancient (and inadequately audited and reviewed, even if not ancient) 
software on ATMs and voting machines should be a scandal. Although they are 
(supposedly) more physically controlled than user desktops/laptops are, and are 
at least INTENDED to be limited to specific kiosk-like functions and nothing 
else, so they're FAR less exposed (software-wise) than a browser accessing 
potentially anything, including once-legit sites that had been hacked to become 
nasty.  The risks are (IMO) NOT THE SAME.

> Or do you think that 50 year old FORTRAN programs on 370 systems should be 
> retired and the entire financial system forced to rewrite code used all 
> around the world?

A heck of a lot had to be fixed for Y2K, and some things that couldn't be fixed 
were either replaced or tossed (including a few that were tossed simply because 
nobody would take responsibility to affirm that they didn't use dates, even 
though it was obvious). Been there, done that. It was only a big yawn-fest due 
to a LOT of hard work. Same thing will happen again in 2038 for any 32-bit 
Unix/Linux code, btw. That won't be modern desktops (just about all of which 
are already 64-bit, some now 64-bit only), but a heck of a lot of embedded 
devices may still be running that old code then. Fortunately I'm retired, so 
assuming I'm still around, I won't have to deal with THAT mess.

>> Sometimes, one has to work with what one has.
> 
> Exactly.

Ok, sometimes. In a retro computing museum. Or in a nonprofit with no budget. 
But for anything serious, one REALLY should be aware of the risks, even if that 
means going back to pen, paper, and snail mail rather than taking the risks. Or 
else realizing that EVERYTHING they do where the information or transaction has 
any value at all, is at greater risk of being corrupted or exploited by 
hostiles if they're doing it on that old system, at least if that system has 
Internet access.

But basically EVERY computer, even if the physical box could last longer, has 
support issues past 5 years old, CERTAINLY if one doesn't have a paid support 
contract. I have a box that's industrial enough that it's 20+ years old and has 
only had a drive or two (mirrored, so never any data loss) replaced, but I 
can't (ok, won't) afford a support contract for it (there probably is still 
support for an older OS version that could still run on it, those things were 
built like tanks!), so I know I'm taking my chances. In other words, no system 
seller is going to be on the hook to support an old system forever as part of 
the purchase price; if they'll provide extended support at all, you'd better 
expect to pay extra for that, every year. EVERYTHING costs, 'cause everybody 
has to make a living, including the rich people and the little people at the 
rich people's companies. Magic no problems forever does NOT exist.

Re: provide latest OS root certificates via port?

[Bill Cole]

On 2021-10-29 at 11:17:52 UTC-0400 (Fri, 29 Oct 2021 11:17:52 -0400 
(EDT))

Richard Bonomo TDS personal 
is rumored to have said:


I don't know what to think about MacPorts, specifically, providing
new certificates, but, pertaining to some of the arguments presented
against doing this on old Macs generally, it must be kept in mind
that some of us --
including yours truly --
have Apple computers that
CANNOT use newer operating systems or browsers.  Sometimes, one has
to work with what one has.


Sure, and I am not saying that MP should abandon older systems or that 
you and I and everyone else still running older systems is doing 
anything "wrong" but simply that it is risky and cannot be safe without 
the recognition that you have to understand and manage your risks 
without vendor support.


Some people have expressed more judgmental views here in the past, 
arguing that older Macs should be relegated to running other, free OSs 
that have active security maintenance and suggesting that MP deprecate 
MacOS versions no longer supported by Apple. I'm NOT saying that, but 
rather that users should understand their risks and MP should not take 
on the doomed task of de facto trying to maintain OS versions which are 
by any reasonable definition obsolete. The norm for MP has been to offer 
parallel tools to those in the OS (e.g. current packages that match what 
Apple used to include in Server) and leave the issue of whether & how to 
user them to actually replace Apple's tools up to the user.






- Original Message -
From: "Bill Cole" 
To: "macports-users Users" 
Sent: Friday, October 29, 2021 10:09:45 AM
Subject: Re: provide latest OS root certificates via port?

On 2021-10-29 at 07:23:38 UTC-0400 (Fri, 29 Oct 2021 07:23:38 -0400)
Richard L. Hamilton 
is rumored to have said:


You're (probably - seems plausible but I haven't verified it myself)
right that that's annoying and fixable.

But there's a big reason to think carefully about whether to do that.
If something is old enough that it isn't receiving certificate
updates, it probably isn't receiving security updates either. And the
same applications and functionality that need current root
certificates to work are also likely to be common attack points.

So at the very least, anything that makes it easier to take such a
risk should come with a prominent warning, IMO.


Yes: Anyone running Mojave or earlier is not exactly skydiving without 
a
parachute, but is doing something close. Perhaps it's akin to 
skydiving

with a homemade parachute...

Frankly, I don't think MacPorts should attempt to 'fix' this issue or
similar future issues diretly, not because it encourages risky 
behavior
but because MacPorts should avoid poking around in the MacOS base at 
all
where it isn't essential for the operation of MacPorts. It's easy 
enough

in principle for MacPorts to stand up and use its own modern OSS-based
encryption+PKI stack with its own set of trusted CAs (e.g.
curl-ca-bundle and openssl ports) and so keep itself functional 
without
poking around in core functionality of the OS that MacPorts-naive 
tools
need to use. People who need to fix the problem of an expired root 
cert
should be able to understand and repair that problem (which can be 
done
without digging a CA bundle out of a newer system) if they need to, 
and

having the issue unaddressed is not itself a security issue, but a
functionality issue. Anyone who actually wants to run Safari & Chrome 
on

an OS that isn't getting basic security maintenance should be thinking
very carefully about what they are doing and accept responsibility for
making something work which arguably should no longer work because it 
is

too risky.

One risk for MacPorts is a slippery slope created by providing support
for antique OS versions that include opaque proprietary bits that are
probably insecure in ways that no one fully understands. If it is 
taken

too far (which in my opinion includes fixing core components like PKI)
MP would be doing a disservice to users who understandably expect a
"Just Works" experience on a Mac by enabling the continued use of 
tools

that could well have permanent unrecognized and mostly invisible
security flaws.



On Oct 29, 2021, at 07:12, René J.V. Bertin 
wrote:

Hi,

Users of older Apple OSes that are no longer receiving updates
probably noticed that Safari and Chrome-based browsers no longer
connect to lots of sites because a crucial root certificate has
expired.

Answer 1 to
https://apple.stackexchange.com/questions/422332/how-do-i-update-my-root-certificates-on-an-older-version-of-mac-os-e-g-el-capi
provides an easy solution, but you need access to an up-to-date OS
install.

These are not proprietary to Apple so I presume it should be 
possible

to provide the suggested `rootcerts.pem` file via a port - possibly
even install it in the post-activate. I had a look but couldn't find
if such a port already exists. I think it'

Re: provide latest OS root certificates via port?

[Michael]

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.

Some sort of "Warning! This system is considered extremely vulnerable" is fine. 
But we see ATM's running windows XP, voting machines running Vista, etc. Old 
systems being used past their expiration date is normal.

Or do you think that 50 year old FORTRAN programs on 370 systems should be 
retired and the entire financial system forced to rewrite code used all around 
the world?

>  Sometimes, one has to work with what one has.

Exactly.

> On 2021-10-29, at 8:17 AM, Richard Bonomo TDS personal  wrote:
> 
> 
> I don't know what to think about MacPorts, specifically, providing
> new certificates, but, pertaining to some of the arguments presented
> against doing this on old Macs generally, it must be kept in mind
> that some of us -- including yours truly -- have Apple computers that
> CANNOT use newer operating systems or browsers.  Sometimes, one has
> to work with what one has.
> 
> Rich
> 
> - Original Message -
> From: "Bill Cole" 
> To: "macports-users Users" 
> Sent: Friday, October 29, 2021 10:09:45 AM
> Subject: Re: provide latest OS root certificates via port?
> 
> On 2021-10-29 at 07:23:38 UTC-0400 (Fri, 29 Oct 2021 07:23:38 -0400)
> Richard L. Hamilton 
> is rumored to have said:
> 
>> You're (probably - seems plausible but I haven't verified it myself) 
>> right that that's annoying and fixable.
>> 
>> But there's a big reason to think carefully about whether to do that. 
>> If something is old enough that it isn't receiving certificate 
>> updates, it probably isn't receiving security updates either. And the 
>> same applications and functionality that need current root 
>> certificates to work are also likely to be common attack points.
>> 
>> So at the very least, anything that makes it easier to take such a 
>> risk should come with a prominent warning, IMO.
> 
> Yes: Anyone running Mojave or earlier is not exactly skydiving without a 
> parachute, but is doing something close. Perhaps it's akin to skydiving 
> with a homemade parachute...
> 
> Frankly, I don't think MacPorts should attempt to 'fix' this issue or 
> similar future issues diretly, not because it encourages risky behavior 
> but because MacPorts should avoid poking around in the MacOS base at all 
> where it isn't essential for the operation of MacPorts. It's easy enough 
> in principle for MacPorts to stand up and use its own modern OSS-based 
> encryption+PKI stack with its own set of trusted CAs (e.g. 
> curl-ca-bundle and openssl ports) and so keep itself functional without 
> poking around in core functionality of the OS that MacPorts-naive tools 
> need to use. People who need to fix the problem of an expired root cert 
> should be able to understand and repair that problem (which can be done 
> without digging a CA bundle out of a newer system) if they need to, and 
> having the issue unaddressed is not itself a security issue, but a 
> functionality issue. Anyone who actually wants to run Safari & Chrome on 
> an OS that isn't getting basic security maintenance should be thinking 
> very carefully about what they are doing and accept responsibility for 
> making something work which arguably should no longer work because it is 
> too risky.
> 
> One risk for MacPorts is a slippery slope created by providing support 
> for antique OS versions that include opaque proprietary bits that are 
> probably insecure in ways that no one fully understands. If it is taken 
> too far (which in my opinion includes fixing core components like PKI) 
> MP would be doing a disservice to users who understandably expect a 
> "Just Works" experience on a Mac by enabling the continued use of tools 
> that could well have perman

Re: provide latest OS root certificates via port?

[Richard L. Hamilton]

I have VMs of a couple of old macOS / OS X versions, because I want continued 
access to the features that have been removed in more recent versions (32-bit 
user land support in Mojave, ability to run PowerPC apps and executables in 
Snow Leopard).

But the old machine that ran Snow Leopard is pretty much dead (why I built a 
Snow Leopard VM with all its apps copied over to replace it before it died 
completely). So everything runs on newer systems, but I can still run the old 
OS versions as VMs if I need them.

One might of course need more $$ to obtain a newer system (although one can 
probably scrounge a deal on a newer enough used one, if one is careful).

So I'm not sure what the limitation would be to ONLY using an old system - 
although if businesses or bureaucrats are involved, limitations may not be 
sensible.

> On Oct 29, 2021, at 11:17, Richard Bonomo TDS personal  wrote:
> 
> 
> I don't know what to think about MacPorts, specifically, providing
> new certificates, but, pertaining to some of the arguments presented
> against doing this on old Macs generally, it must be kept in mind
> that some of us -- including yours truly -- have Apple computers that
> CANNOT use newer operating systems or browsers.  Sometimes, one has
> to work with what one has.
> 
> Rich
> 
> - Original Message -
> From: "Bill Cole" 
> To: "macports-users Users" 
> Sent: Friday, October 29, 2021 10:09:45 AM
> Subject: Re: provide latest OS root certificates via port?
> 
> On 2021-10-29 at 07:23:38 UTC-0400 (Fri, 29 Oct 2021 07:23:38 -0400)
> Richard L. Hamilton 
> is rumored to have said:
> 
>> You're (probably - seems plausible but I haven't verified it myself) 
>> right that that's annoying and fixable.
>> 
>> But there's a big reason to think carefully about whether to do that. 
>> If something is old enough that it isn't receiving certificate 
>> updates, it probably isn't receiving security updates either. And the 
>> same applications and functionality that need current root 
>> certificates to work are also likely to be common attack points.
>> 
>> So at the very least, anything that makes it easier to take such a 
>> risk should come with a prominent warning, IMO.
> 
> Yes: Anyone running Mojave or earlier is not exactly skydiving without a 
> parachute, but is doing something close. Perhaps it's akin to skydiving 
> with a homemade parachute...
> 
> Frankly, I don't think MacPorts should attempt to 'fix' this issue or 
> similar future issues diretly, not because it encourages risky behavior 
> but because MacPorts should avoid poking around in the MacOS base at all 
> where it isn't essential for the operation of MacPorts. It's easy enough 
> in principle for MacPorts to stand up and use its own modern OSS-based 
> encryption+PKI stack with its own set of trusted CAs (e.g. 
> curl-ca-bundle and openssl ports) and so keep itself functional without 
> poking around in core functionality of the OS that MacPorts-naive tools 
> need to use. People who need to fix the problem of an expired root cert 
> should be able to understand and repair that problem (which can be done 
> without digging a CA bundle out of a newer system) if they need to, and 
> having the issue unaddressed is not itself a security issue, but a 
> functionality issue. Anyone who actually wants to run Safari & Chrome on 
> an OS that isn't getting basic security maintenance should be thinking 
> very carefully about what they are doing and accept responsibility for 
> making something work which arguably should no longer work because it is 
> too risky.
> 
> One risk for MacPorts is a slippery slope created by providing support 
> for antique OS versions that include opaque proprietary bits that are 
> probably insecure in ways that no one fully understands. If it is taken 
> too far (which in my opinion includes fixing core components like PKI) 
> MP would be doing a disservice to users who understandably expect a 
> "Just Works" experience on a Mac by enabling the continued use of tools 
> that could well have permanent unrecognized and mostly invisible 
> security flaws.
> 
> 
>>> On Oct 29, 2021, at 07:12, René J.V. Bertin  
>>> wrote:
>>> 
>>> Hi,
>>> 
>>> Users of older Apple OSes that are no longer receiving updates 
>>> probably noticed that Safari and Chrome-based browsers no longer 
>>> connect to lots of sites because a crucial root certificate has 
>>> expired.
>>> 
>>> Answer 1 to 
>>> https://apple.stackexchange.com/questions/422332/how-do-i-update-my-root-certificates-on-an-older-version-of-mac-os-e-g-el-capi
>>>  
>>> provides an easy

Re: provide latest OS root certificates via port?

[Richard Bonomo TDS personal]

I don't know what to think about MacPorts, specifically, providing
new certificates, but, pertaining to some of the arguments presented
against doing this on old Macs generally, it must be kept in mind
that some of us -- including yours truly -- have Apple computers that
CANNOT use newer operating systems or browsers.  Sometimes, one has
to work with what one has.

Rich

- Original Message -
From: "Bill Cole" 
To: "macports-users Users" 
Sent: Friday, October 29, 2021 10:09:45 AM
Subject: Re: provide latest OS root certificates via port?

On 2021-10-29 at 07:23:38 UTC-0400 (Fri, 29 Oct 2021 07:23:38 -0400)
Richard L. Hamilton 
is rumored to have said:

> You're (probably - seems plausible but I haven't verified it myself) 
> right that that's annoying and fixable.
>
> But there's a big reason to think carefully about whether to do that. 
> If something is old enough that it isn't receiving certificate 
> updates, it probably isn't receiving security updates either. And the 
> same applications and functionality that need current root 
> certificates to work are also likely to be common attack points.
>
> So at the very least, anything that makes it easier to take such a 
> risk should come with a prominent warning, IMO.

Yes: Anyone running Mojave or earlier is not exactly skydiving without a 
parachute, but is doing something close. Perhaps it's akin to skydiving 
with a homemade parachute...

Frankly, I don't think MacPorts should attempt to 'fix' this issue or 
similar future issues diretly, not because it encourages risky behavior 
but because MacPorts should avoid poking around in the MacOS base at all 
where it isn't essential for the operation of MacPorts. It's easy enough 
in principle for MacPorts to stand up and use its own modern OSS-based 
encryption+PKI stack with its own set of trusted CAs (e.g. 
curl-ca-bundle and openssl ports) and so keep itself functional without 
poking around in core functionality of the OS that MacPorts-naive tools 
need to use. People who need to fix the problem of an expired root cert 
should be able to understand and repair that problem (which can be done 
without digging a CA bundle out of a newer system) if they need to, and 
having the issue unaddressed is not itself a security issue, but a 
functionality issue. Anyone who actually wants to run Safari & Chrome on 
an OS that isn't getting basic security maintenance should be thinking 
very carefully about what they are doing and accept responsibility for 
making something work which arguably should no longer work because it is 
too risky.

One risk for MacPorts is a slippery slope created by providing support 
for antique OS versions that include opaque proprietary bits that are 
probably insecure in ways that no one fully understands. If it is taken 
too far (which in my opinion includes fixing core components like PKI) 
MP would be doing a disservice to users who understandably expect a 
"Just Works" experience on a Mac by enabling the continued use of tools 
that could well have permanent unrecognized and mostly invisible 
security flaws.


>> On Oct 29, 2021, at 07:12, René J.V. Bertin  
>> wrote:
>>
>> Hi,
>>
>> Users of older Apple OSes that are no longer receiving updates 
>> probably noticed that Safari and Chrome-based browsers no longer 
>> connect to lots of sites because a crucial root certificate has 
>> expired.
>>
>> Answer 1 to 
>> https://apple.stackexchange.com/questions/422332/how-do-i-update-my-root-certificates-on-an-older-version-of-mac-os-e-g-el-capi
>>  
>> provides an easy solution, but you need access to an up-to-date OS 
>> install.
>>
>> These are not proprietary to Apple so I presume it should be possible 
>> to provide the suggested `rootcerts.pem` file via a port - possibly 
>> even install it in the post-activate. I had a look but couldn't find 
>> if such a port already exists. I think it'd help for lots of 
>> people... I'd propose a draft but I'm running 10.9 ... so thanks to 
>> anyone picking this up!
>>
>> R.
>>


-- 
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

Re: provide latest OS root certificates via port?

[Bill Cole]

On 2021-10-29 at 07:23:38 UTC-0400 (Fri, 29 Oct 2021 07:23:38 -0400)
Richard L. Hamilton 
is rumored to have said:

You're (probably - seems plausible but I haven't verified it myself) 
right that that's annoying and fixable.


But there's a big reason to think carefully about whether to do that. 
If something is old enough that it isn't receiving certificate 
updates, it probably isn't receiving security updates either. And the 
same applications and functionality that need current root 
certificates to work are also likely to be common attack points.


So at the very least, anything that makes it easier to take such a 
risk should come with a prominent warning, IMO.


Yes: Anyone running Mojave or earlier is not exactly skydiving without a 
parachute, but is doing something close. Perhaps it's akin to skydiving 
with a homemade parachute...


Frankly, I don't think MacPorts should attempt to 'fix' this issue or 
similar future issues diretly, not because it encourages risky behavior 
but because MacPorts should avoid poking around in the MacOS base at all 
where it isn't essential for the operation of MacPorts. It's easy enough 
in principle for MacPorts to stand up and use its own modern OSS-based 
encryption+PKI stack with its own set of trusted CAs (e.g. 
curl-ca-bundle and openssl ports) and so keep itself functional without 
poking around in core functionality of the OS that MacPorts-naive tools 
need to use. People who need to fix the problem of an expired root cert 
should be able to understand and repair that problem (which can be done 
without digging a CA bundle out of a newer system) if they need to, and 
having the issue unaddressed is not itself a security issue, but a 
functionality issue. Anyone who actually wants to run Safari & Chrome on 
an OS that isn't getting basic security maintenance should be thinking 
very carefully about what they are doing and accept responsibility for 
making something work which arguably should no longer work because it is 
too risky.


One risk for MacPorts is a slippery slope created by providing support 
for antique OS versions that include opaque proprietary bits that are 
probably insecure in ways that no one fully understands. If it is taken 
too far (which in my opinion includes fixing core components like PKI) 
MP would be doing a disservice to users who understandably expect a 
"Just Works" experience on a Mac by enabling the continued use of tools 
that could well have permanent unrecognized and mostly invisible 
security flaws.



On Oct 29, 2021, at 07:12, René J.V. Bertin  
wrote:


Hi,

Users of older Apple OSes that are no longer receiving updates 
probably noticed that Safari and Chrome-based browsers no longer 
connect to lots of sites because a crucial root certificate has 
expired.


Answer 1 to 
https://apple.stackexchange.com/questions/422332/how-do-i-update-my-root-certificates-on-an-older-version-of-mac-os-e-g-el-capi 
provides an easy solution, but you need access to an up-to-date OS 
install.


These are not proprietary to Apple so I presume it should be possible 
to provide the suggested `rootcerts.pem` file via a port - possibly 
even install it in the post-activate. I had a look but couldn't find 
if such a port already exists. I think it'd help for lots of 
people... I'd propose a draft but I'm running 10.9 ... so thanks to 
anyone picking this up!


R.




--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

Re: provide latest OS root certificates via port?

[Richard L. Hamilton]

You're (probably - seems plausible but I haven't verified it myself) right that 
that's annoying and fixable.

But there's a big reason to think carefully about whether to do that. If 
something is old enough that it isn't receiving certificate updates, it 
probably isn't receiving security updates either. And the same applications and 
functionality that need current root certificates to work are also likely to be 
common attack points.

So at the very least, anything that makes it easier to take such a risk should 
come with a prominent warning, IMO.

> On Oct 29, 2021, at 07:12, René J.V. Bertin  wrote:
> 
> Hi,
> 
> Users of older Apple OSes that are no longer receiving updates probably 
> noticed that Safari and Chrome-based browsers no longer connect to lots of 
> sites because a crucial root certificate has expired.
> 
> Answer 1 to 
> https://apple.stackexchange.com/questions/422332/how-do-i-update-my-root-certificates-on-an-older-version-of-mac-os-e-g-el-capi
>  provides an easy solution, but you need access to an up-to-date OS install.
> 
> These are not proprietary to Apple so I presume it should be possible to 
> provide the suggested `rootcerts.pem` file via a port - possibly even install 
> it in the post-activate. I had a look but couldn't find if such a port 
> already exists. I think it'd help for lots of people... I'd propose a draft 
> but I'm running 10.9 ... so thanks to anyone picking this up!
> 
> R.
> 

provide latest OS root certificates via port?

[René J . V . Bertin]

Hi,

Users of older Apple OSes that are no longer receiving updates probably noticed 
that Safari and Chrome-based browsers no longer connect to lots of sites 
because a crucial root certificate has expired.

Answer 1 to 
https://apple.stackexchange.com/questions/422332/how-do-i-update-my-root-certificates-on-an-older-version-of-mac-os-e-g-el-capi
 provides an easy solution, but you need access to an up-to-date OS install.

These are not proprietary to Apple so I presume it should be possible to 
provide the suggested `rootcerts.pem` file via a port - possibly even install 
it in the post-activate. I had a look but couldn't find if such a port already 
exists. I think it'd help for lots of people... I'd propose a draft but I'm 
running 10.9 ... so thanks to anyone picking this up!

R.