This might be a little out of place because it is likely common knowledge, and I just missed it.
Are packages just blindly updated from upsteam or is there some kind of preliminary audit?
Looking back at the xz backdoor issue, I am worried that something much less sophisticated or even obvious could make it to my machine without either human or automated review. I do understand that no big project is exempt from vulnerabilities and the like, so I am restricting my question to blatant ones or at least not as complex as the xz one.
I’ve read there are (ongoing) efforts to both make arch packages reproducible (I have no knowledge about it, but in my research I’ve seen mixed opinions about the effectiveness of it in this case) and to have an automated checking code similar to the xz’s backdoor (https://github.com/hlein/distro-backdoor-scanner) but I still am unsure about the auditing itself.
Regardless of the amount of auditing, how could I mitigate or reduce the effect of malicious packages from upstream? What about detecting if something is wrong?
Best advise I can give here is don’t update constantly, update 1 to 2 times a month, keep an eye on the forums for information that may rely to packages you have installed/rely on and any other useful info before updating. And always keep backcups on a seperate disk/USB etc
BTW @CoffeeTime welcome to the forum
Well the issue is that at the end of day. Someone needs to be looking at the code. It is either you, upstream, or the community. For some packages lots of people look at the code. For other packages, no one looks at the code. There are so many packages that no one is looking at all of the code. Perhaps some kind of security scanning software can be put into Arch’s build infrastructure (I’m not sure on this), but that isn’t going to stop all vulnerabilities and I’m not convinced it would have caught the xz vulnerability.
If I’m not mistaken, the xz vulnerability only existed in specific binary packaging, not xz broadly. So again, if I’m not mistaken, if you’d built xz from source yourself, you would not have inherited the vulnerability.
It was in this way that other systems, such as FreeBSD, essentially side-stepped the vulnerability, as it uses a separate binary packaging workflow.
So, that presents the option then. Build your own packages from source. You might even go down the Gentoo or FreeBSD path and build everything from source (or at least have the option to).
The problem it solves, is that at least you have certainty the system and packages you’re using, are built from the source you can see (should you wish to). You might even get the added benefit of binaries optimised for your specific hardware.
The problem it creates, is the mountain of time and effort needed to maintain an up-to-date system where everything is built from source. As @d-air1 also alluded to, it’s also unlikely that because we can review the source, we do review the source, or carry the skill to do so.
My general approach is to keep what’s installed to a minimum. If you’re not using it and it’s not integral to the system, remove it (or opt out of installing it in the first place).
Unless we build our systems from scratch and audit each and every line of code used to build the binaries run on them, we are at the mercy of those who have the knowledge, possibility and time to do it on our behalf.
Given the sheer number of the packages available out there, this is a “Herculean task” and not practically feasible by a limited number of common mortals.
We daily drive our safe and secure Linux systems on “blind faith”.
@smokey Thank you, I am happy to be here! I’m not so sure avoiding updating is a good idea since I would pass on bug fixes and patches. I feel like this would be a way of emulating a stable release distro; maybe that is what I am looking for (at least until kde 6.2) but at the same time I am worried about backports of patches may not be as effective. However, keeping an eye on the forums and news is an awesome idea.
@Bink I think the idea behind reproducible builds is to trust the build process without building each package from source. Looking at https://reproducible.archlinux.org/ core and extra are largely reproducible so, if I am correct, we may be enjoying a similar degree of trust as actually building from source!
The idea of keeping what’s installed to a minimum is actually quite smart! I could use flatpak/podman/distrobox extensively for packages that are not integral to the system, with the side effect of also reducing the amount of maintenance needed.
I do agree with @pebcak that auditing such a big amount of packages (reading from the reproducible builds page, there are 13633 packages in the [extra] repository) is simply not humanly doable, but focusing on [core]/packages integral to the system might be.
Welcome,
No, usually, package maintainers check if there’s some errors/warnings during compilation and the software can be launched with no problem. It doesn’t mean they scan the source code or test every functions/settings.
Some years ago, a dev was “annoyed” Debian stable kept using an old version of his software so he put a warning in the app, and Debian people didn’t notice.
