Can’t believe he figured it out. What a shame. Guess we’ll have to go provoke another country to invade our fellow flourishing independent democracies, who play a key role in the world’s trade.
Seriously though, I hope he’s just giving himself an easy out here. There’s always too much war going on.
This is a great start, but tbh, I’m not fully sold on “verified” flathub apps. Verification requires a token to be placed into a source repo or a website, but there appears to be nothing on actually verifying that the source/site are the original creators. So, for example, if someone packaged a malicious version of librefox and established it under io.github.librewolf-community instead of the canonical io.gitlab.librewolf-community, I’m concerned it’ll still show as verified (though quickly removed). The process can be read about here.
It’s funny, because there was research done by UC Riverside which specifically figured out LTS branches receive patches for CVEs significantly later than vendor specific branches. Specifically:
Interestingly, we note that the picked CVE patches appear in distributions 74.2 days earlier than LTS on average;
They also conveniently left out the part of Greg KH’s opinion stating that he recommends the use of vendor kernels over stable/LTS branches, too.
I found this particularly funny:
It all comes down to a delicate balancing act between security and stability. Some top Linux kernel developers and CIQ are coming down on the side of security.
Now I know CIQ is “supposedly” different from rocky, but what is CIQ going to do, break bug-for-bug compat and use stable kernels in their supported version of Rocky? This entire article feels like it doesn’t fundamentally understand that not all bugs (especially ones that lead to potential low-ranking CVEs) aren’t worth patching.
It’s not that they can’t, it’s that people are getting blindsided by updates to a game which supposedly hasn’t received updates for over half a decade, and downgrading on Steam is a surprisingly huge PITA. The Midnight Ride recommends patching, fwiw.
I wouldn’t place too much faith in the vetting process. As of right now, there are 2,034 members of the packager group of Fedora. None of them are required to have 2FA (or any real account security past a password), and the minimum requirements to join the group aren’t very high (contribute a package, pick up an unmaintained one, etc). Any of those 2,034 people can push malware to Fedora, and within a week, it’d be in stable repos.
Most of these distros are volunteer efforts. They don’t have the manpower to ensure the software supply chain remains secure.
That’s barely the tip of the iceberg, too. Currently, popular projects sit at:
31M for KDE
25M for GNOME
41M for Chromium
42M for Mozilla Firefox
17M for LLVM
15M for GCC
(Note that this metric includes comments and blank lines, to which Linux would count at 46M lines. Counts with blank lines and comments removed are also in those links)
Even if a package was completely vetted, line-by-line, before it made it into a repo, would the maintainer need to get every update, too? Every PR? Imagine the maintenance burden. This code QA and maintainer burden discussion was the crux of one of the most popular discussions on the Fedora devel list.
The entire thing. It needs to be completely rewritten in rust, complete with unit tests and Miri in CI, and converted to a high performance microkernel. Everything evolves into a crab /s
If anyone’s curious, here’s the RHBZ ticket listing the products RH has patched this in: https://bugzilla.redhat.com/show_bug.cgi?id=2262126
This is not April fools. The submitter did want to mess with people, though.
By the way, all Fedora packages are scanned with ClamAV as part of bodhi tests. Here’s the test matrix where xz 5.6.0 passed the scan, and would have allowed the exploit in for the F40 beta if it wasn’t obsoleted by another build where the vulnerability’s mechanism was disabled because it triggered valgrind failures in other software.
Sure, there’s more sophisticated AV software out there, but at the end of the day, the F40 beta was temporarily saved because of luck, the beta freeze period, and valgrind. The ecosystem as a whole was saved because “Jia Tan” wasn’t aware that making Postgres run slightly slower immediately raises alarm bells.
To everyone saying you can’t mirror a flatpak repo… you’re absolutely right. There should be a far easier way to set up your own mirror without needing to build everything from scratch. That being said, if you wanted to try to make your own repo with every one of flathub’s apps, here you go:
https://github.com/flathub
https://docs.flatpak.org/en/latest/hosting-a-repository.html
Edit: Some did get a flathub mirror working. The issue is that a. Fastly works good enough and b. There is no concept of “packages” on the server side. It’s just one big addressed content store because of ostree, and syncing is apparently difficult? Idk, not being able to sync the state of content is like the entire point of ostree…
https://github.com/flathub/flathub/issues/813