Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 580722 - dev-libs/nss & app-misc/ca-certificates: drop SPI certificate & change cacert default to off
Summary: dev-libs/nss & app-misc/ca-certificates: drop SPI certificate & change cacert...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-04-21 12:52 UTC by Hanno Böck
Modified: 2016-12-03 21:01 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Hanno Böck gentoo-dev 2016-04-21 12:52:22 UTC
The package ca-certificates currently installs a certificate
spi-cacert-2008.crt
This certificate belongs to "Software in the Public Interest", an organization with ties to Debian that issued certificates in the past. They stopped doing so and all Debian-related hosts that previously used certificates from this CA have moved to other CAs.

Debian itself removed this certificate recently from their installations and there shouldn't be any use in the wild any more:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796208

This certificate is currently installed when the use flag cacert is enabled (but it's +cacert in IUSE, so this is the default). This doesn't make any sense (it seems this was created due to confusion about cacert/spi, they're not the same thing).

Anyway: I think there is no legitimate reason to keep this certificate any more and it should not be installed.
Comment 1 SpanKY gentoo-dev 2016-04-21 16:41:51 UTC
the binding of spi to cacert was more laziness.  they're largely the same class of certs, so having a single USE flag was easier.

including cacert itself is not really necessary anymore with the rise of LE.  we can flip that default off.

same goes for nss -- ca-certificates is just matching the nss policy.
Comment 2 Hanno Böck gentoo-dev 2016-04-21 20:45:05 UTC
I agree that cacert should be default off or completely removed (I just planned to open another bug for it). I have a slight preference for complete removal and just stay with "upstream" ca-certificates. If there's a wish for keeping an ebuild-ish way to install the cacert root it could still live in its own package (but the relevance of cacert is rapidly declining, so I doubt that).
Comment 3 SpanKY gentoo-dev 2016-04-22 03:54:39 UTC
(In reply to Hanno Boeck from comment #2)

technically upstream Debian ca-certificates still includes cacert ...
Comment 4 SpanKY gentoo-dev 2016-04-22 18:11:19 UTC
let's double check that the infra guys aren't still relying on cacerts.  if they are, let's make sure the systems are updated to explicitly list USE=cacert so we can land these changes.
Comment 5 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2016-04-24 23:26:09 UTC
Infra has been on real commercial certificates for a few years now. Additionally, as Hanno says, LetsEncrypt is a very good replacement for all website usage.
Comment 6 Ian Stakenvicius (RETIRED) gentoo-dev 2016-04-25 16:05:50 UTC
So what should the resolution be here?  drop IUSE="+cacert" and both patches, or just change "+cacert" to "cacert" and drop the spi patch?  Or..
Comment 7 SpanKY gentoo-dev 2016-04-25 16:18:00 UTC
(In reply to Ian Stakenvicius from comment #6)

i'm going to drop SPI and change +cacert to cacert
Comment 8 Ian Stakenvicius (RETIRED) gentoo-dev 2016-06-08 00:32:18 UTC
(In reply to SpanKY from comment #7)
> (In reply to Ian Stakenvicius from comment #6)
> 
> i'm going to drop SPI and change +cacert to cacert

Ok, i've done this in dev-libs/nss-3.24 (committing today).  Should I do this in older versions as well?
Comment 9 Ian Stakenvicius (RETIRED) gentoo-dev 2016-07-09 02:55:26 UTC
(In reply to Ian Stakenvicius from comment #8)
> (In reply to SpanKY from comment #7)
> > (In reply to Ian Stakenvicius from comment #6)
> > 
> > i'm going to drop SPI and change +cacert to cacert
> 
> Ok, i've done this in dev-libs/nss-3.24 (committing today).  Should I do
> this in older versions as well?

OK *actually* committed this time, to dev-libs/nss-3.25-r1
Comment 10 Cor Legemaat 2016-07-16 07:44:59 UTC
This broke cacert on 3.25-r1, probably need cacert section from "${DISTDIR}/${PN}-3.14.1-add_spi+cacerts_ca_certs.patch"
Comment 11 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2016-10-05 11:22:41 UTC
commit ae5b9090020c2d5b6f74458110571a9664bee49a
Author: Lars Wendler <polynomial-c@gentoo.org>
Date:   Wed Oct 5 09:58:56 2016

    app-misc/ca-certificates: Don't install obsolete spi-cacert-2008.crt

    This is an attempt to fix bug #580722.

    Package-Manager: portage-2.3.1
    Signed-off-by: Lars Wendler <polynomial-c@gentoo.org>


Is that change sufficient to fix this bug?
Comment 12 Sergey 'L29Ah' Alirzaev 2016-10-11 00:39:52 UTC
What's the purpose of removing cacert from the trusted pack?
Comment 13 Daniel Neugebauer 2016-10-28 13:13:49 UTC
Just wanted to let you know that it wasn't a nice move to deprecate CACert without prior warning. This caused at least bug #598200 for our overlay as we are still signing with CACert as it provides 6-month certificates. While I already planned to look into LE as a replacement I didn't find enough time recently as it strictly requires automation, else it's just unbearable (it just uses a cycle of 90 days which is much too frequent to change manually). The ACME clients which are available right now are not the best, especially not app-crypt/acme which is the only one available from the official portage tree right now. I would have preferred if you had provided easier access to better ACME clients at least a few months before you disabled cacert - after all you want all users to switch to LE but how?!

It would have been better if the USE flag would have kept enabled for "legacy systems", i.e. systems that had it enabled before. I'm not entirely sure but I think I've seen a feature to retain USE flags on legacy setups before (maybe by using virtual packages which keep the flag enabled?). Would have been great if it would have been kept enabled for users who had CACert installed in the past...
Comment 14 Ian Stakenvicius (RETIRED) gentoo-dev 2016-10-28 14:56:58 UTC
(In reply to Daniel Neugebauer from comment #13)
> It would have been better if the USE flag would have kept enabled for
> "legacy systems", i.e. systems that had it enabled before. I'm not entirely
> sure but I think I've seen a feature to retain USE flags on legacy setups
> before (maybe by using virtual packages which keep the flag enabled?). Would
> have been great if it would have been kept enabled for users who had CACert
> installed in the past...

Unfortunately it is impossible to do what you suggest here from a repository or ebuild perspective.  Package managers (with appropriate flags) do show what use flags have changed state compared to what's currently installed, but that is as far as we can go as package maintainers.

Also, part of the point of disabling the flag by default is to drop the cacert flags from systems that had it installed in the past (since nearly ALL systems had it installed in the past), but the users didn't care about it.  We left the flag so that users that do want it can explicitly enable this in their use flag selections.
Comment 15 Michalis Adamidis 2016-10-30 09:55:23 UTC
So to sum up:
In order to remove a single root certificate that seemingly cannot be used anymore anyways you deprecate a whole class of certificates despite them possibly having a valid use case and there might be a whole lot of people actually using them.

Wasn't this desision a bit over the line _especially_ without pre warning i.e. through the eselect news system?
Comment 16 Arfrever Frehtes Taifersar Arahesis 2016-10-30 12:53:07 UTC
Usage of nss-3.14.1-add_spi+cacerts_ca_certs.patch was dropped in dev-libs/nss:
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0f07ec40931c5b549ddf9919a4f25b9101304487

But not in app-misc/ca-certificates:
https://gitweb.gentoo.org/repo/gentoo.git/commit/app-misc/?id=ae5b9090020c2d5b6f74458110571a9664bee49a

Maybe the first part of that patch should be extracted into a new patch which would still be applied with USE="cacert" (as suggested in comment #10)?
Comment 17 Arfrever Frehtes Taifersar Arahesis 2016-12-03 20:40:21 UTC
New changes in dev-libs/nss:
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=22aa8bae27e2d4856f31bb1e722e42c3d4aa237d

New changes in app-misc/ca-certificates:
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=bfffe8f5ca618ddc48b0d7c9c9890024f0020e50
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a0f5804d717546de8a979d7d3783d9d9c8a64a40

So as of dev-libs/nss-3.27.2 and app-misc/ca-certificates-20161102.3.27.2-r2, SPI certificate is never added and CAcert certificates (Class 1 PKI Key and Class 3 PKI Key) are added with USE="cacert" (by nss-cacert-class1-class3.patch).

This bug seems to be properly fixed now.