Isn't that just Ubuntu being idiotic as usual?

Ubuntu has never seemed to take security particularly seriously.

So yes shipping a CA known to have intentionally issued false certificates is very on-brand for them.

The more I see it the more I think Ubuntu's "job" is "take a sensible Debian distribution and just fucking break shit in it"

Their strong point has always been design and branding. I love their fonts and a few years ago they were the only ones with a patched libfreetype that didn't make your eyes bleed.

As for engineering decisions, let's just say better stick with debian on anything non-desktop.

The only issue with Debian is if you want the latest version of some application, e.g. Firefox then installing it is far from a nice experience. And Debian testing is quite unstable (I run it on my laptop so I know).

Love it for my servers but it is not very convenient for the desktop.

I wish Debian would release 20.04 LTS, 22.04 LTS and so on.

That is the big feature of Ubuntu for me. Can set in my calendar when it's time to migrate services to the next version.

I have been running Debian Stable on my (gaming/coding/general use) desktop and on my work laptop for close to a decade now, and I have had very few problems, things just work. The last problem of "too old system libraries" nature I remember was maybe 5 years ago, when Steam client did not work because of too old glibc, but one Debian release later the problem was gone.

I don't think it's as bad as most people think it is, nowadays.

Flatpak exists; Nix exists; Guix exists. All of them make it easy to have newer software without caring about your Debian package versions.

There are other issues with Debian. They will radically rearrange upstream software to follow their own standards (e.g. try using Tomcat on Debian sometime). This is bad enough when they apply it to regular software, and downright insane when they do the same thing for security-critical software. It predictably caused quite possibly the worst general-purpose OS bug in history (their SSL key generation one). They did not change their policy in response to that incident and see nothing wrong.

That may or may not be the case, but this incident is not evidence for it, since Debian did the same thing. See upthread: https://news.ycombinator.com/item?id=33879202

Oh no, our terrible secret is out! :)

>So yes shipping a CA known to have intentionally issued false certificates is very on-brand for them.

Did TrustCor turn out to have done that? The last time I checked in on that, the distrust was mainly founded on some not-very-trustworthy behavior involving spyware in a related company within the same corporate umbrella.

To be removed, a CA just needs to show it is not worthy of trust.

TrustCor met this requirement and got removed.

Other CAs removed in the past also showed they are unworthy of trust, but in even more blatant ways.

Yes - I know - I'm responding to the accusation in the quote, which is not at all substantiated.

You misunderstood the accusation as being leveled against TrustCor when in fact the commenter was referring to Symantec

You’re 100% right. They were unable to convince the right folks that they were trustworthy, and they appear to be in a prime position to abuse misplaced trust due to some fundamental conflicts of interest, but “known to have intentionally issued false certificates” is a false accusation.

I was referring to Ubuntu shipping Symantec.

The removal of Symantec was a bit questionable as well. There is reason for strictness here, but I don't think having used their certs a bit longer was a relevant security threat at all.

Trustcor allegedly spread spyware, which I do think makes anyone untrustworthy. But it should be checked if allegations can be confirmed.

> Ubuntu has never seemed to take security particularly seriously.

I haven't heard that before. Care to elaborate what we do that makes you believe we don't take security seriously?

I think that claim is overblown, but, basically, Canonical weighs security decisions differently than some people would like (me included).

The main comparison is Debian, for obvious reasons. Debian tends to be a bit faster at applying upstream security patches.

Another example is usually binned as "privacy", but has security implications - and that's the bullshit they played with leaking your search requests to Amazon and calling it a convenience, putting ads in the motd, stuff like that.

Again, my personal view is this is less a problem than some other folks. I wish they were faster, and I think their side-hustles in advertising and such are tacky and gross. But I don't see that problem as bad enough to ditch them, or even yell to loudly.

The bug report quite clearly states that Ubuntu followed the same revert that Debian did: "The Debian ca-certificates package removed this CA for both TLS (expected) and other uses (like timestamping) (unexpected). Trust was added back in a subsequent update."

So no, Ubuntu didn't do anything wrong or unreasonable here.

Edit:

Here's the Debian revert that Ubuntu followed:

ca-certificates (20200601~deb10u2) buster; urgency=medium ... Revert Symantec CA blacklist (#911289). Closes: #962596, #968002.

From https://tracker.debian.org/media/packages/c/ca-certificates/...

Interestingly, this time around, Ubuntu actually removed TrustCor from its root store almost immediately. That technically means that some certificates that should still be valid are now invalid on Ubuntu.

> ...where Ubuntu just unilaterally reverted Mozilla’s removal of a cert in their package, because it was breaking nuget

It wasn't unilateral. Ubuntu followed Debian here, who did the same revert: https://tracker.debian.org/media/packages/c/ca-certificates/...

> where Ubuntu just unilaterally reverted Mozilla’s removal of a cert in their package, because it was breaking nuget… Note that this was early 2021 — Mozilla removed Symantec from their trust store in October 2018!

Mozilla actually removed the certs from their trust store in February 2021: https://hg.mozilla.org/projects/nss/rev/9718a34c84429b1e5dc6...

Debian and Ubuntu had jumped the gun by a few weeks and there were certificates still being used that had not been renewed yet, so we had to revert temporarily.

Mozilla had used the CKA_NSS_SERVER_DISTRUST_AFTER tag with a date to specify newer certs issued by that CA were not valid, but as the article above states, the crypto libraries being used in Linux don't support that kind of thing.

My mistake, I misread “Removal/distrust” in the timeline of https://wiki.mozilla.org/CA/Symantec_Issues as meaning removal from the trust store.

I can’t edit my comment now, but hopefully your correction here gets upvoted and is visible to people.

For those who are interested in more details about this, I wrote a paper that examines the delay and trust discrepancies between Mozilla and its derivative root stores (e.g., Linux, NodeJS, etc.): https://zanema.com/papers/imc21_roots.pdf