Message-ID: <d05beba38245b383980044d49630636920b95792.camel@cogitri.dev>
Subject: Re: Extraneous roots in current ca-certificates package
From: Rasmus Thomsen <oss@cogitri.dev>
To: Filippo Valsorda <filippo@ml.filippo.io>, 
	~alpine/devel@lists.alpinelinux.org
Cc: Natanael Copa <ncopa@alpinelinux.org>
Date: Mon, 13 Apr 2020 08:39:43 +0200
In-Reply-To: <95406ebc-f823-4215-a6d8-bbc0ee4ffec3@www.fastmail.com>
References: <f17a2a73-020a-46d0-bc45-1ddc261f8e7e@www.fastmail.com>
	 <80CC10B3-3DF8-4DB8-8119-A705C901B24C@cogitri.dev>
	 <95406ebc-f823-4215-a6d8-bbc0ee4ffec3@www.fastmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Sun, 2020-04-12 at 18:07 -0400, Filippo Valsorda wrote:
> 2020-04-12 17:34 GMT-04:00 Rasmus Thomsen <oss@cogitri.dev>:
> > 
> > Hello,
> > 
> > thanks for your message! (although a Gitlab issue with hidden 
> > visibility probably would've been better).
> 
> Thank you for the quick response!
> 
> > On April 12, 2020 9:00:43 PM UTC, Filippo Valsorda 
> > <filippo@ml.filippo.io> wrote:
> > > 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.
> > 
> > Sure, I'll update it if no one beats me to it.
> > 
> > >        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.
> > 
> > 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, 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).
> 
> > >    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.
> > 
> > Ah yes, we probably missed those since there were no explicit CVEs
> > for 
> > old versions AFAICS 
> 
> Oh, that's a good point, we should bring up getting CVEs for
> distrusts with Mozilla.

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).

> > > 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.
> > 
> > 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".

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

> Cheers,
> Filippo
> 
> > Regards,
> > 
> > Rasmus Thomsen
> > 
> > > Thanks for your work on Alpine,
> > > Filippo