Subject: Extraneous roots in current ca-certificates package

From: "Filippo Valsorda" <[email-masked]>
Date: Sun, 12 Apr 2020 17:00:43 -0400

Hello,

I recently ran a comparison of the root stores of Linux distributions
with the Mozilla store, and found a couple issues:

    1. There are a dozen or so certificates in ca-certificates 20191127
(latest) that shouldn't be there. I think this was due to an issue in
the Python script that was used to extract them. The new perl script
from curl in git.alpinelinux.org/ca-certificates master is doing the
right thing, so the fix should simply be to make a new release of the
package.

        a. By the way, I would suggest adding a line to the "update"
make target to download the latest version of mk-ca-bundle.pl as well,
as the certdata.txt format changes over time and new distrust settings
might get added. I can send a patch, but it's trivial enough that it
might just cause you more work.

    2. The Alpine branches that are still receiving security fixes
only, v3.8-v3.10, have out of date ca-certificates packages which
include roots distrusted due to severe security issues like Certinomis
<https://wiki.mozilla.org/CA/Certinomis_Issues> and TurkTrust
<https://blog.mozilla.org/security/2013/01/03/revoking-trust-in-two-turktrust-certficates/>.
I think changes in the CA root store easily qualify as security fixes,
and updates to ca-certificates should be propagated to all supported
versions.

By the way, I would have cc'd a security contact, but I could not
find one on the website and it looks like the team might not have one
<https://gitlab.alpinelinux.org/alpine/infra/infra/issues/9698>, which
is a bit concerning.

Thanks for your work on Alpine,
Filippo

---

From: Rasmus Thomsen <[email-masked]>
Date: Sun, 12 Apr 2020 21:34:51 +0000

Hello,

thanks for your message! (although a Gitlab issue with hidden visibility probably would've been better).
>right thing, so the fix should simply be to make a new release of the

Sure, I'll update it if no one beats me to it.

>might just cause you more work.

Hm, right now we patch in the version curl uses, and we try to avoid downloading data in APKBUILDs that isn't checksummed by abuild so I'm not sure if we want to do that.

>and updates to ca-certificates should be propagated to all supported

Ah yes, we probably missed those since there were no explicit CVEs for old versions AFAICS 

><https://gitlab.alpinelinux.org/alpine/infra/infra/issues/9698>, which

Since we've switched to Gitlab, the best way to reach us for security concerns is probably to add a Gitlab issue with the visibility set to "hidden". That way every team member can see the issue, add additional comments to it and refer to it in commits. We make it public once the issue has been dealt with then, so users know about past security issues. This is also how we handle CVEs of packaged software right now.

Regards,

Rasmus Thomsen

---

From: "Filippo Valsorda" <[email-masked]>
Date: Sun, 12 Apr 2020 18:07:37 -0400

2020-04-12 17:34 GMT-04:00 Rasmus Thomsen <[email-masked]>:
> 
> 
> Hello,
> 
> thanks for your message! (although a Gitlab issue with hidden 
> visibility probably would've been better).

Thank you for the quick response!

> Hm, right now we patch in the version curl uses, and we try to avoid 
> downloading data in APKBUILDs that isn't checksummed by abuild so I'm 
> not sure if we want to do that.

I mean the "update" target in the ca-certificates repo, which AFAICT is
run to fetch a new certdata.txt to be checked in. mk-ca-bundle.pl should
simply get the same treatment.

https://git.alpinelinux.org/ca-certificates/tree/Makefile?id=898ab81b51730dcd175069956d6e792385c9f457#n38

> Ah yes, we probably missed those since there were no explicit CVEs for 

Oh, that's a good point, we should bring up getting CVEs for distrusts with Mozilla.

> Since we've switched to Gitlab, the best way to reach us for security 
> concerns is probably to add a Gitlab issue with the visibility set to 
> "hidden". That way every team member can see the issue, add additional 
> comments to it and refer to it in commits. We make it public once the 
> issue has been dealt with then, so users know about past security 
> issues. This is also how we handle CVEs of packaged software right now.

That sounds totally fine, but it's not really discoverable. May I
suggest listing these instructions somewhere prominent on the website?
I usually just load the website and grep the home, about, contact and
community pages for "security".

Cheers,
Filippo

---

From: Rasmus Thomsen <[email-masked]>
Date: Mon, 13 Apr 2020 08:39:43 +0200

> https://git.alpinelinux.org/ca-certificates/tree/Makefile?id=898ab81b51730dcd175069956d6e792385c9f457#n38

Ah yes, I guess we can just fetch that ourselves, thanks. However, I
think it's best if we just make proper pkgversion bumps at that point
(so that we not only upgrade that file but download the latest
snapshot).
> > > <
> > > https://blog.mozilla.org/security/2013/01/03/revoking-trust-in-two-turktrust-certficates/>
> > > ;.
> > Ah yes, we probably missed those since there were no explicit CVEs
> > for 
> > old versions AFAICS 
> 

That'd help a lot - AFAICS we don't really have a way to know when we
need to get a new release out for ca-certificates (and FWIW proper
releases from Mozilla would help _a lot_ here already).

> > > <https://gitlab.alpinelinux.org/alpine/infra/infra/issues/9698>;,
> > > which
> > > is a bit concerning.
> > 

Ah yes, we should probably add that to the website, thanks!

The following MRs upgrade ca-certificates on all supported branches:

* https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/6731
* https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/6732
* https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/6733

---

From: "Ariadne Conill" <[email-masked]>
Date: Mon, 13 Apr 2020 08:20:04 +0000

Hello,

> right thing, so the fix should simply be to make a new release of the

The python script was originally from Debian, you may wish to report this to them as well.

> <https://blog.mozilla.org/security/2013/01/03/revoking-trust-in-two-turktrust-certficates>.

I agree, but without CVEs or some other feedback mechanism, low profile issues slip through the cracks.  It would be nice for CVEs to be assigned when Mozilla distrusts a CA.

> <https://gitlab.alpinelinux.org/alpine/infra/infra/issues/9698>, which

Historically, we have not had a designated security contact, but opening an issue on the tracker and designating it a security issue will ensure that it gets directed to somebody who can quickly solve the problem.

We should update the website to reflect this.

Ariadne