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.
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.
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).
(In reply to Hanno Boeck from comment #2) technically upstream Debian ca-certificates still includes cacert ...
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.
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.
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..
(In reply to Ian Stakenvicius from comment #6) i'm going to drop SPI and change +cacert to cacert
(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?
(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
This broke cacert on 3.25-r1, probably need cacert section from "${DISTDIR}/${PN}-3.14.1-add_spi+cacerts_ca_certs.patch"
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?
What's the purpose of removing cacert from the trusted pack?
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...
(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.
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?
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)?
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.
