MS could update your OS to do anything tomorrow, Canonical could hide some literal malware in any number of packages for Ubuntu tonight, Intel could write a backdoor into your machine in it's next microcode update.
And OSS doesn't fully prevent this either. GCC could add some kind of nefarious exploit in the next version of it's compiler (knowingly or otherwise). Just take a look at the underhanded c competition for just how scary easy it is to hide exploits in plain sight!
I can't even fathom the amount of work it would be to personally review every line of code that goes into your machine from the microcode up to the newest NPM module (even if it were all open and it was possible to do). At some point you need to trust someone else.
That's why betrayals of trust - such as adding spyware that takes data without the user's informed consent ("opt-out") - are such a big problem.
You're right - there isn't enough time to audit everything, so we have to rely on trust. "Relying on trust" means instead of reviewing code, you have to review trustworthiness.
MS could update your OS to do anything tomorrow, Canonical could hide some literal malware in any number of packages for Ubuntu tonight, Intel could write a backdoor into your machine in it's next microcode update.
And OSS doesn't fully prevent this either. GCC could add some kind of nefarious exploit in the next version of it's compiler (knowingly or otherwise). Just take a look at the underhanded c competition for just how scary easy it is to hide exploits in plain sight!
I can't even fathom the amount of work it would be to personally review every line of code that goes into your machine from the microcode up to the newest NPM module (even if it were all open and it was possible to do). At some point you need to trust someone else.