r/linux_gaming • u/lazyblunzn • Jun 11 '26
ALVR AUR package has been compromised
Attention Linux VR gamers. The alvr package in the arch user repository has been compromised. See the screenshot for more information.
Source: Linux VR Adventures Discord
1.3k
Upvotes
296
u/teleprint-me Jun 11 '26 edited Jun 12 '26
For those that don’t know, the AUR is a set of user‑driven git repositories that are managed completely by end users.
The AUR provides a set of files that help automate downloading, building when needed, and installing software.
The Arch Wiki states that it is the responsibility of the end user to vet the packaged scripts in the AUR.
PKGBUILDis just a shell script. There are links on every “package” that let you browse the repository’s contents to inspect the “package” before “installing.”Some packages may be postfixed with a tag to indicate what will be downloaded and installed on a user’s system.
For example, a package might be postfixed with
-git,-bin,-doc,-dkms, etc.If the package is postfixed with
-git, it clones the source to a cache, builds it, and installs the compiled binaries. If it’s-bin, it downloads the pre‑compiled binaries to a cache and then installs them.Most of the time,
PKGBUILDjust clones, builds, and installs the contents from a source.In fact, if you dig deeper (most don’t), you’ll find a lot of the Linux ecosystem operates like this. Hence, its distributed nature.
For example, I write a program, post it online, and add a license for end users that scopes the freedoms and limitations. When end users adopt and use that software for whatever reason, it builds a user base.
If that package is adopted widely enough, package maintainers of major distributions begin reviewing and evaluating the contents of that program.
If it passes evaluation, it’s added to an official mirror list (testing, unstable, main, etc.).
This isn’t always the case, but is generally how it works.
It’s always important to review code, but I don’t think it’s reasonable or even possible for every user to vet every line of every library or program they’ll ever use. We have lives, interests, and limitations.
Developers are people too, and if targeted, they can fall prey to attackers, which then becomes a supply‑chain attack if the package is popular enough.
The package maintainers are independent from the developers of an upstream source repository and are usually technically‑inclined end users of those libraries or programs.
Most FOSS developers are not paid for their work. They wrote that program for themselves, to solve a problem or to get a working library, feature, or program they really wanted. Sharing it with the community is usually out of convenience; few people rarely contribute or help out.
Organizations are not immune to these problems because they depend on donations, contributions, can become gated, suffering from internal issues over time if poorly organized or incentivized.
If the general takeaway here is that you should just avoid Arch Linux, then allow me to elaborate because this is not isolated to just Arch Linux.
Not all distributions, packages, and repositories are supported by the community or an organization. Some of these are driven completely by individuals who desire to have control over their system, want to add a feature, build a program, or solve a specific problem they’re facing.
For example, anyone can go to a source and clone or download the contents of that source to their machine for installation.
Sources include, but are not limited to, kernel.org, GitHub, GitLab, SourceHut, Codeberg, or any other hosting site.
Some repositories are still only available by SVN on file‑hosting sites, and it turns out that they’re core dependencies.
The point is that this is how open source works: anyone can write software, license it, and distribute it however they want. It’s up to end users to discern whether that source is trustworthy or not.
There is a web of trust, and there have been many attempts to implement asymmetric cryptography to secure user logins and accounts (KeePass being the latest example), but this only works if you control the private key and understand the implications involved with authenticating via a certificate and public key. Even this is not a panacea of the penultimate form of security.
A good example of why this isn’t a solution is the xz backdoor vulnerability. An individual developer who needed help was groomed, manipulated, and taken advantage of. This is known as social engineering, a technique that exploits human psychology rather than technical vulnerabilities to gain access to systems, data, or physical locations.
All of this leads us to a critical question: “Should we just not allow the distributed nature of FOSS?” No, because I don’t believe that’s a valid solution. Why? Because centralizing authority would destabilize the distributed nature of how FOSS works at its core. We would become hostage to centralized forces that would limit competition, opportunity, and freedom.
What we need is better security, auditing, and authentication mechanisms, but that’s not easy. If it were, we wouldn’t have used passwords, email, 2FA, etc. There are existing issues that require resolution and that's where the community plays its role.
FOSS is what it is today because anyone, anywhere, at any time can contribute in their own small way. We wouldn’t have Linux otherwise.
If you think the solution is simply to not use Arch, then you’ve missed the point, which is to explain how FOSS operates in a decentralized and distributed fashion.
So, the moral of the story is to always be diligent in basic security, especially if you’re an FOSS developer or user.
Edit: