FS#59690 - [ca-certificates] Reconsider CAcert inclusion

Attached to Project: Arch Linux
Opened by userwithuid (userwithuid) - Friday, 17 August 2018, 14:41 GMT
Last edited by Doug Newgard (Scimmia) - Friday, 24 August 2018, 03:10 GMT
Task Type General Gripe
Category Packages: Core
Status Closed
Assigned To Jan Alexander Steffens (heftig)
Architecture All
Severity Very Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

I suggest changing ca-certificates-cacert to not be a hard-dependency of ca-certificates any more.

My main goal is to prevent CAcert from being trusted in a default Arch base install. Least invasive would be to make it an optional dep, most thorough to remove it and add a "conflicts" to "fix" existing installs as well.
This task depends upon

Closed by  Doug Newgard (Scimmia)
Friday, 24 August 2018, 03:10 GMT
Reason for closing:  Implemented
Additional comments about closing:  ca-certificates-20180821-1
Comment by userwithuid (userwithuid) - Friday, 17 August 2018, 14:41 GMT
--verbose

A lot has changed since CAcert has been added(+removed+readded) to Arch. From what I gather, CAcert is only in Arch because it seemed like a good idea once and nobody changed it since.

* RedHat/Fedora never added it, Debian/Ubuntu have disabled it years ago (2014/2015), it's optional in SUSE, the BSDs don't have it, actually hardly anyone but Gentoo and Arch still do. It never got included in any of the major root stores (Apple/Google/Java/Microsoft/Mozilla).

* Let's Encrypt provides free fully trusted server certs. Free mail certs from trusted roots can be had as well (why anyone would bother with smime nowadays is another matter).

* Meanwhile Google, Mozilla and others have actually done a lot to fix the "broken" CA system so that you might actually be able to - somewhat - trust the public CAs in the root programs soon. This does not apply to CAcert though, both in terms of policies/audits but also in terms of real-world technical differences, i.e. Certificate Transparency enforcement. Security improvements that made it into the Baseline requirements for CAs or Mozilla/Google policy are not implemented by CAcert. Though I doubt they do, CAcert still _could_ pretty much sign and MITM whatever and nobody would notice or care - like in the good old days or on systems with a private CA installed.

* Is there even any real-world use case for having CAcert trusted in Arch when nobody else trusts it or ever will? On the other hand, the presence of a legacy root cert with no oversight from anyone or anything could very well be considered a security risk.
Comment by Jan Alexander Steffens (heftig) - Tuesday, 21 August 2018, 18:20 GMT
I completely agree.
Comment by Giancarlo Razzolini (grazzolini) - Tuesday, 21 August 2018, 20:14 GMT
+ 1 for removal.
Comment by Damjan Georgievski (damjan) - Tuesday, 21 August 2018, 21:50 GMT
+1 removal

I'd just suggest there's a period of "depreciation" when people would be clearly informed of the removal of the package (and their options).
Comment by Caleb Maclennan (alerque) - Wednesday, 22 August 2018, 07:11 GMT
+1 for removal. Maybe even a few years later than should have been done. Having it available to install on as as-wanted basis is fine, but requiring it on a base system install is not. I'm also for the conflicts tag so that it gets removed by default. Sysadmins should have to deliberately want and add the package if they have some special case that requires access to those certs. In order to avoid conflicts perhaps the *-cacert package could be renamed to something else so a conflicts rule could get rid of the current packages, but a separate new package could be installed by those who want it without tripping over the conflict rule.
Comment by Jan Alexander Steffens (heftig) - Wednesday, 22 August 2018, 07:13 GMT
If you want to re-add the cacert certs without removing the ca-certificates metapackage you just need to rebuild it with a pkgrel bump; the conflicts/replaces are versioned.

Loading...