Ubuntu Pro is a subscription offering for Ubuntu users who want to pay for the assurance of getting quick and high-quality security updates for Ubuntu. I tested it out to see how it works in practice, and to evaluate how well it works as a commercial open source service model for Linux.\n
Paying for services isn’t philosophically incompatible with FOSS, that’s how companies like RedHat broke through back in the day, but paying for “quick and high-quality security updates” strikes me as alarming. Am I to take from that that they’re holding back high-quality security updates from some users? Unless maybe we’re talking about extended support for EoL software.
Ubuntu Pro gives you 5 more years of security updates for versions that are EoL. You can see it here if you scroll down to the maintenance schedule https://ubuntu.com/security/esm
Glad to hear it’s extended maintenance for old software and not making their private users less secure.
Unfortunately, it’s both. They also hold back security updates for non-latest releases that are still covered under Standard support. I work in an environment where we track new CVEs for our builds, and we constantly see vulnerabilities for 22.04 that are fixed in Pro but not made available otherwise.
Sure, technically you can opt into Pro as an individual user without paying, but it puts everyone who uses off the shelf installs and containers at risk and is therefore an immoral and unethical process in my opinion.
I take it your build is dependant on the community-maintained Universe repo?
https://ubuntu.com/security/cves/about#security
https://help.ubuntu.com/community/Repositories/Ubuntu
https://askubuntu.com/questions/1452497/what-are-esm-apps-and-how-do-they-relate-to-ubuntu-pro
If they already to the work for esm-apps repo then they could at least send those fixes over to the universe repo until the release version is EoL one would think. On the other hand I have no idea what lives in universe and what lives in main.
That was a rabbit hole.
Well, correct me if I’m wrong, but RedHat also had more recent updates compared to CentOS, while also being certified.
None of this affects what happened “back in the day” which is what I was talking about.
That said, my understanding of the current packaging philosophy of RHEL/CentOS Stream is that embargoed security fixes go in to RHEL first, then to CentOS Stream once the embargo is lifted (that’s pretty much as you’d expect), otherwise everything goes in to CentOS Stream first. Unless you have counter-examples I’ve not heard of?