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
Hello,
thanks for your message! (although a Gitlab issue with hidden visibility probably would've been better).
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.
> 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
>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.
Regards,
Rasmus Thomsen
>Thanks for your work on Alpine,>Filippo
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> > 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.
> >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".
Cheers,
Filippo
> Regards,> > Rasmus Thomsen> > >Thanks for your work on Alpine,> >Filippo>
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
Hello,
On April 12, 2020 3:00 PM, "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.
The python script was originally from Debian, you may wish to report this to them as well.
> > 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.
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.
> 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.
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