Tim Cook reads every single LOC submitted to his OS.
He does? Highly unlikely.
Diffs are examined for sure. I remember that firsthand.
This is unrealistic. Read everything represents too much work.
Dude. I actually have sources for most of my installed packages lying around, because Gentoo. Do you know how much space that source code takes up?
Just under 70GB. And pretty much everything but maybe the 10GB of direct git pulls is compressed, one way or another.
That means that even if your distro is big and has 100 people on development, they would each have to read 1GB or more of decompressed source just to cover the subset of packages installed on my system.
How fast do you read?
I’m looking at bringing Dillo back into Gentoo atm. I had to read 15k lines of code, and that’s just what’s different since the last release…
Lol read and understand it.
These days you are likely running some code nobody read closely.
The author trusted AI and didn’t fully understand it.
The maintainer trusted the author and merged because the change sounded good and the tests passed and they are grateful anyone contributed at all.
The packager trusted the maintainer. The security team trusted the packager. The user trusted the distro.
no
No
Should … Should we tell OP that nobody understands all of any moderately large codebase, especially the sub-dependencies … or that even the thousands of developers who wrote most of that code don’t understand how their own code works anymore?
I could read the same book every year and I still won’t remember most of the minor events on my deathbed. Doesn’t mean I won’t remember the key components that make up the story — coding is like that, except the minor events and key components can be rewritten or removed by someone else whenever you go to read them next.
that even the thousands of developers who wrote most of that code don’t understand how their own code works anymore?
The bugs I have fixed that were written by that idiot “me from a few weeks/months/years ago”…
That guy sounds like the dude that “works” at my house too.
several times I have searched for a problem and found my own stackoverflow question with no replies.
The worst thing is when it happens in this way and you can’t remember even though it was your own question https://xkcd.com/979/
It’s a web of trust. If the package maintainer is doing due diligence they should at least be aware how the upstream community runs. If it’s a one person passion project then it’s probably possible to give the changelog and diffstata once over because things don’t change that fast. Otherwise they are relying on the upstream not shipping broken stuff.
deleted by creator
No, distros instead use a web of trust in the maintainers. New maintainers are vetted and established ones are assumed to not suddenly turn into malicious actors.
There’s an ongoing project that tries to bootstrap a Debian system from a seed that’s small enough to be read, but it’s more of a proof of concept at this stage, and even this project requires trust into a few parts up front (like xz of all things).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.
Any of those 2,034 people can push malware to Fedora
Maybe, but that is still a significantly higher bar than allowing everyone to publish a package the way most language specific package repositories work (or just use any random github repo even like some others).
TempleOS doesn’t have a repo I think so its dev writes and reads 100% of the code. I also heard of a tty-only Linux distro project that didn’t have a repo but I’m not sure
Boy do I have news for you…
Probably Guix, and GNU endorsed distributions. Binary blobs are not allowed on free/libre distributions, or not on their official repos. That said, most gnu + linux distributions don’t care about those. Most will take care, if they get to realize it, about distribution licenses, so if something has some sort of legal issue to be distributed, that will get purged from its repos most probably…
Aaah, so that’s why it takes them so long to update packages.
I’ll bet you anything they’re not reading the code for every random package and dependency. But yeah, with free distros it’s at least possible to read everything that’s on your machine.
I’d bet you they don’t. It would be an impossible task to expect people to do.
I wonder if you could use AI for this
@ihatelinux Nobody does that. It’s totally infeasible.
Not any Linux distro.
You can probably read small hobby operating systems like SerenityOS and understand them whole, but you’ll still need to trust clang or gcc, because those are too big to read.
Why would they do this?
Also, if you wanted to do this yourself, it is technically possible. Go build LFS and read every single LOC.
The kernel alone has more than 30,000,000 LOC. Alone reading would take forever and a day for a single person, let alone understand it.
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.
It is bonkers that a fucking Web Browser has more LOC than a Desktop Environment
It’s even more bonkers than it sounds. If you look at the code locations for that KDE count, you’ll see it also includes just about every KDE project. That’s not just Plasma, that’s hundreds of projects, including some really big ones like Krita, Kdenlive, Calligra, LabPlot, Kontact, Digikam and Plasma Mobile. Hell, it even includes KHTML/KJS, KDE’s defunct web engine as well as the ancestor of WebKit and Blink. It even includes AngelFish and Falkon, KDE’s current web browser frontends.
Same deal with GNOME. It includes just about everything on GNOME’s GitLab, even things that are merely hosted there without strictly being GNOME projects, like GIMP and GTK.
And yet still they are both that far behind Chromium and Firefox. Modern web browsers are ludicrous.
Finally, presumably if anyone added some malicious code in a their program, it would be sneaky and not obvious from quickly reading the code.
I’d expect them to properly comment it with “#-------Begin malicious shit--------”.
COMMENT YOUR CODE, PEOPLE!The exploit should be written in a way that it is obvious and doesn’t need commenting!
Oh, in that case we don’t need to read either - just run a simple grep!
Those malicious coders are too sly for that. Some write “Sh1t” to throw grep off, others even do a “B3g1n”… They are always one step ahead!
Good point. I’d try to grep for something like
[Bb3][Ee3]g[Ii1][nη]\w+<and so on>but I just know I’ll miss something
Well yeah, the recent xz vulnerability was not present in the source code at all. Any amount of code reading would not have caught that one.
Wasn’t the problem that
itthe backdoor was not present in the source code on GitHub, but was in the source tarball? So as long as one reads the code that one actually builds from should be fine.A line of code that enables the backdoor was out present in the tarball. The actual code was obfuscated within an archive used for the unit testing.
OK. So simply reading what was readable wouldn’t have helped. Thanks.
