ca-certificates 2021-07-05 (new formula)

[Bo98]

• Have you followed the guidelines for contributing?
• Have you ensured that your commits follow the commit style guide?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

---

Also, stop using the keychain on Yosemite and El Capitan, since these versions don't have the Let's Encrypt root.

I have not tested this on a 10.10 VM yet, but will before merging to make sure the PEM route actually works.

[carlocab]

Let's just make this a separate formula. It's in use in multiple formulae anyway.

[Bo98]

Not sure of the best strategy for that.

Ideally we'd handle the keychain stuff there and then the file can be used by multiple formula. But the problem is we currently use openssl in that processing. A bit of a chicken and egg problem.

[Bo98]

Or maybe /usr/bin/openssl is enough actually. I forget that still exists.

[carlocab]

I don't follow -- the cacert resource is used only in post_install_from_pem, where no openssl binary is needed. Where do we need openssl here?

Or, I guess alternatively we can just use /etc/ssl/cert.pem. Is there any reason why we don't want that one?

[Bo98]

I don't follow -- the cacert resource is used only in post_install_from_pem, where no openssl binary is needed. Where do we need openssl here?

The keychain part. I've just pushed what I was thinking of.

Or, I guess alternatively we can just use /etc/ssl/cert.pem

I can't recall the differences between that and the keychain, but we're going to want to avoid that on older macOS anyway since it's severely outdated.

[carlocab]

I was thinking of making this a Linux- and old-macOS-only dependency, so that we can keep the keychain post_install in this formula. This way we can still do depends_on "cacert" in gnutls, which currently has its own logic for generating the CA cert bundle.

[Bo98]

gnutls does the exact same Keychain stuff. I'm not sure I follow how there wouldn't be a conditional in gnutls as well.

[carlocab]

It's not exactly the same:

homebrew-core/Formula/gnutls.rb

Lines 104 to 112 in c30079a

	# XXX And drop Kerberos certs which may invalidate the whole trust store
	# due to bug in gnutls (https://gitlab.com/gnutls/gnutls/-/issues/1255)
	IO.popen("openssl x509 -inform pem -issuer -noout 2>/dev/null", "r+") do |openssl_io|
	openssl_io.write(cert)
	openssl_io.close_write
	cn = openssl_io.read
	openssl_io.close_read
	cn.exclude? "CN=com.apple.kerberos.kdc"
	end

[Bo98]

Honestly, I see no reason why that can't apply to OpenSSL as well. It's a self-signed Kerberos certificate - not a SSL root certificate.

[Bo98]

The general idea I have here is I would also like to get rid of the copy paste chaos we have where I have to make the same change in 3 different places. Plus decoupling CA cert updates from an OpenSSL & GnuTLS revision bump is nice.

[Bo98]

Oh and to resolve #54235 finally.

[carlocab]

Oh and to resolve #54235 finally.

@FiloSottile will be pleased to learn about this. (Apologies for the ping, but this stuff seems to be in your wheelhouse, so it'd be nice to hear your thoughts here too.)

[Bo98]

@FiloSottile will be pleased to learn about this.

Just to summarise, the idea is:

HOMEBREW_PREFIX/etc/cacert/cert.pem is the only copy on the system (or whatever we call the formula).

HOMEBREW_PREFIX/etc/openssl@1.1/cert.pem is a symlink to the above. Same with those in gnutls, openssl@3 etc.

[Bo98]

@Homebrew/core I know this topic has come up on a number of occasions on Slack so here's a ping if you're interested (and sorry if you're not).

[Bo98]

I’m not sure I understand the choice of merging the Mozilla and Apple root stores. Is it just to bring in the Let’s Encrypt root on older macOS versions?

Yes.

Could it be scoped to only systems that are not getting updates from Apple?

Apple seem to rarely update older trust stores. The Mojave cert store, for example, has not been modified since the 2019-002 security update (December 2019). Catalina's cert store has not been modified since June 2020 (presumably 10.15.6). Monterey (beta) meanwhile was updated a month ago.

So "not getting update from Apple" might be anything that's not the latest version.

I did a quick skim of the logic, but it seems to ignore the root purposes: in a store you can have roots trusted for email, code signing, Kerberos, TLS… you usually only want to extract the latter.

Yep I absolutely agree. This should have been added when the keychain was expanded beyond Apple roots. I've added a restriction to the "SSL Client CA" and "SSL Server CA" purpose.

-p ssl would probably also work with verify-cert but apparently that starts making network calls.

The Mozilla store also has purposes, but what you get depends on where you download it. Maybe curl did the filtering for you.

Curl store filters to only include SERVER_AUTH.

[FiloSottile]

Yep I absolutely agree. This should have been added when the keychain was expanded beyond Apple roots. I've added a restriction to the "SSL Client CA" and "SSL Server CA" purpose.

You probably want only "SSL Server CA", which are the ones actually bound by the Baseline Requirements. (It also matches curl's SERVER_AUTH.)

[Bo98]

Yep I absolutely agree. This should have been added when the keychain was expanded beyond Apple roots. I've added a restriction to the "SSL Client CA" and "SSL Server CA" purpose.

You probably want only "SSL Server CA", which are the ones actually bound by the Baseline Requirements. (It also matches curl's SERVER_AUTH.)

Yeah kinda just realised after pushing. Fixed now!

[carlocab]

Won't this make everyone have the post_install done twice when they brew upgrade or brew install openssl@1.1 once this is merged? I can see why we need it, but I wonder if there's a way to avoid doing this twice in a single brew invocation.

We can save this for later though.

[Bo98]

I can probably drop this in favour of regular ca-certificates updates & revision bumps, which is what we should be doing.

[carlocab]

Just noticed we used to ship a CA bundle: Homebrew/legacy-homebrew#28658

This doesn't necessarily have any bearing on what we're doing here today, but I thought I'd link this here for anyone who needs to look up things we've done before and the reasons for them.

[Bo98]

So many chickens, so many eggs.

10.14 audit of course fails because it needs Homebrew/brew#12167, but Homebrew/brew#12167 in turn needs this PR.

Anyhow, this should be good to go.

[BrewTestBot]

@Bo98 has triggered a merge.

[carlocab]

🐔 🥚 🐔

[carlocab]

Not an all bottle. Very strange.

[carlocab]

Timestamps are off:

❯ diffoscope ca-certificates--2021-09-30.arm64_big_sur.bottle.tar.gz ca-certificates--2021-09-30.mojave.bottle.tar.gz
--- ca-certificates--2021-09-30.arm64_big_sur.bottle.tar.gz
+++ ca-certificates--2021-09-30.mojave.bottle.tar.gz
├── filetype from file(1)
│ @@ -1 +1 @@
│ -gzip compressed data, was "ca-certificates-bottle.tar", last modified: Thu Sep 30 21:42:41 2021, from Unix
│ +gzip compressed data, was "ca-certificates-bottle.tar", last modified: Mon Oct  4 02:43:56 2021, from Unix
│   --- ca-certificates--2021-09-30.arm64_big_sur.bottle.tar
├── +++ ca-certificates--2021-09-30.mojave.bottle.tar
│ ├── file list
│ │ @@ -1,6 +1,6 @@
│ │ -drwxr-xr-x   0        0        0        0 2021-09-30 21:42:41.000000 ca-certificates/2021-09-30/
│ │ -drwxr-xr-x   0        0        0        0 2021-09-30 21:42:41.000000 ca-certificates/2021-09-30/.brew/
│ │ --rw-r--r--   0        0        0     4226 2021-09-30 21:42:41.000000 ca-certificates/2021-09-30/.brew/ca-certificates.rb
│ │ -drwxr-xr-x   0        0        0        0 2021-09-30 21:42:41.000000 ca-certificates/2021-09-30/share/
│ │ -drwxr-xr-x   0        0        0        0 2021-09-30 21:42:41.000000 ca-certificates/2021-09-30/share/ca-certificates/
│ │ --rw-r--r--   0        0        0   203007 2021-09-30 21:42:41.000000 ca-certificates/2021-09-30/share/ca-certificates/cacert.pem
│ │ +drwxr-xr-x   0        0        0        0 2021-10-04 02:43:56.000000 ca-certificates/2021-09-30/
│ │ +drwxr-xr-x   0        0        0        0 2021-10-04 02:43:56.000000 ca-certificates/2021-09-30/.brew/
│ │ +-rw-r--r--   0        0        0     4226 2021-10-04 02:43:56.000000 ca-certificates/2021-09-30/.brew/ca-certificates.rb
│ │ +drwxr-xr-x   0        0        0        0 2021-10-04 02:43:56.000000 ca-certificates/2021-09-30/share/
│ │ +drwxr-xr-x   0        0        0        0 2021-10-04 02:43:56.000000 ca-certificates/2021-09-30/share/ca-certificates/
│ │ +-rw-r--r--   0        0        0   203007 2021-10-04 02:43:56.000000 ca-certificates/2021-09-30/share/ca-certificates/cacert.pem

[Bo98]

That is really weird and makes no sense. I could try a rebottle? It definitely was working in one of the attempts here, and I've only been fiddling with postinstall since.

[carlocab]

I'll poke at it; go to bed.

[MikeMcQuaid]

Great work here!

[MikeMcQuaid]

I'd be tempted to just inline these.