The AUR doesn’t host application sources, those come from upstream. PKGBUILDs are pretty short. Reading a PKGBUILD takes only a couple of minutes (or less) at the initial install, and for subsequent updates you’re only checking the diffs, which generally only takes a few seconds.
@Sermor I’m sympathetic to your larger point. But you seem to be painting a rather extreme profile of an “expert” and then knocking it down as an unrealistic standard for those who are less-knowledgeable users. Sort of a “straw man” argument.
Certainly there’s a middle ground in here somewhere, i.e., where developing some level of expertise is key when relying (safely) on a distro like Arch.
Where we disagree: Yes indeed, users of FOSS are ultimately responsible for what they use. If not them, then whom?
That’s the deal… it’s free and it’s open source. No purchase necessary. Therefore, the usual consumer/vendor product protections don’t apply.
Meanwhile, distro gurus want their software to work well, to be respected (and respectful), and to be useful to a delineated community.
Toward that end, that’s why the AUR is “platformed” by Arch - yet this is done without clear and outright ownership. It’s a way to strike a balance.
Where we clearly agree: It’s become evident by current events that some kind of re-balancing is now warranted. 
I really appreciate the feedback from everyone, and I’m glad we’re having this discussion. Instead of replying individually, I’d like to address the core points raised in the previous comments right here.
I fully respect and agree with your preference for the “do-it-yourself” philosophy, however, there’s a fundamental difference between system configuration (do-it-yourself) and supply chain security.
Choosing my own desktop environment, kernel, and software is “do-it-yourself.” But expecting a single user to analyze thousands of lines of upstream source code for hidden vulnerabilities or malicious commits isn’t “do-it-yourself”—it’s humanly impossible, even for the most experienced hobbyist.
When I talk about shifting responsibilities, I don’t mean EndeavorOS having to decide what software to install on my PC. I mean the entire ecosystem (upstream developers, package maintainers, and security protocols) must evolve because “just read the source code yourself” is no longer a viable security model for anyone in the current threat landscape.
The “just don’t use it if you don’t like the terms” argument works well for choosing a hobby, but it fails when discussing the reality of modern cybersecurity. No matter how big and red the disclaimer is, it doesn’t magically give a user the physical hours required to review millions of lines of code flowing into their system every week.
We aren’t talking about forcing every distro to act like Ubuntu or macOS. We are talking about recognizing that “use at your own risk” has become a shield to avoid fixing broken, outdated trust models in the open-source ecosystem. Acknowledging a problem is the first step to improving it, not killing the project.
Glancing at a PKGBUILD diff takes a few minutes, yes, but it only shows you how the package is being built, not what is hidden inside the thousands of lines of source code it is downloading. If a reputable upstream developer gets compromised (or turns malicious), their package will look perfectly normal and clean in your daily diff.
The threat isn’t just in obscure AUR packages; it’s in the infrastructure we all trust blindly.Saying “nobody is expected to audit code” while simultaneously claiming “it’s sustainable because you can just glance at a diff” is a contradiction. A glance is not security; it’s just security theater. IHMO.
I really appreciate the thoughtful and nuanced tone of your response. You strike at the core of the philosophical debate here.
To answer your question: “If not the user, then whom?” – I don’t mean we need a corporate vendor to sue when things go wrong. In FOSS, there is no vendor, and we all know that.Instead, we need to separate the responsibility of usage from the responsibility of integrity.
If I use Debian, Fedora, or even Mint, I am still 100% responsible for how I manage my system. If I run reckless commands or use weak passwords, that is on me. However, those distributions have a curated repository infrastructure and a security superstructure that dramatically lightens the auditing burden.
They don’t force me to operate at a code-auditing level just to stay safe from upstream poisoning.The responsibility must shift from individual user vigilance to systemic infrastructure. The burden shouldn’t be on the end-user to catch malicious commits; it should be on the ecosystem to implement stronger supply chain verification, reproducible builds, and automated sandboxing.I’m glad we agree that a re-balancing is warranted.
My critique isn’t a straw man against having expertise; it’s against the idea that “individual expertise” can scale to defend against modern, state-sponsored supply chain threats. We need collective, structural defenses, because a 1990s legal disclaimer is no longer a viable security architecture for the world we live in today.
That’s true, but at that point we’re no longer talking about the AUR.
If the upstream project itself is compromised, then the problem extends far beyond the AUR. The same malicious source code could end up in any distribution that packages it, including official repositories.
At some point, trust becomes unavoidable. None of us can realistically audit every upstream project we use, whether it comes from the AUR, Arch’s official repos, Debian, Fedora, or anywhere else. If we rejected every package unless we personally reviewed its entire source code, we’d have to stop using not just the AUR, but practically every operating system.
For me, the goal is to reduce risk where it’s practical: use reputable packages, minimize unnecessary AUR dependencies, review PKGBUILD changes, and be cautious when something looks unusual. Beyond that, you’re relying on the same trust model that the entire open-source ecosystem depends on.
So are you ready to pay for it? The reality is that takes time and as you yourself pointed out People have Jobs. Linux is basically a Hobbyist System when it comes down to it since its community run. We (The Community) don’t have the infrastructure or the finances to put into this kind of “Evolution”
And no its not just paying for the developers its also paying for the Lawyers for when the system fails to check something now people want to sue. Again this isn’t a Corporate project with tons of money involved this is a community project with tons of time involved instead.
I mean when you go to the Park who is really in charge of Your security? You are again just blindly trusting that Penny Penchers will always follow the rules and never cut corners. Just look at the state of Windows by cutting corners they have A.I do a large part of their coding now. Is that what you want to trust to tell you something is safe?
I think this view creates a false dichotomy: either we keep the 1990s “buyer beware” model, or we become a corporate behemoth like Microsoft full of lawyers.
But the FOSS world has already proven there is a third way. Look at Debian. It is an entirely community-run, volunteer-driven, non-corporate project. They don’t have billions of dollars or a legal team waiting to be sued. Yet, they managed to build a security superstructure, curated repositories, and a trust model that protects users infinitely better than a simple “good luck” disclaimer. It’s a matter of architecture and process, not budget.
As for the park analogy: if I trip over my own shoelaces at the park, that’s on me. But if the city builds a public bridge with rotten wood and it collapses under my feet, we don’t blame the citizen for not performing a structural engineering audit before crossing.
We don’t need to pay developers millions to implement reproducible builds or cryptographic signatures; we just need to agree as a community that the way we package and verify software must evolve to match the modern threat landscape.
I agree that Debian has built an excellent trust model, but that also comes with trade-offs. Debian’s development model, release cycle, and package curation are very different from Arch’s. The price you pay is a much slower pace of change and newer software often takes much longer to reach users.
Ultimately, that’s why different distributions exist. Everyone has to decide where they want to sit on the spectrum between stability, security, trust in the distribution’s curation, freshness, and convenience. There isn’t a single model that fits everyone’s needs.
Arch expects users to take on more responsibility in exchange for more flexibility and up-to-date software. Debian makes different trade-offs. Neither approach is inherently wrong—they’re just optimized for different priorities.
I don’t understand the point of this comparison to be honest.
Debian isn’t auditing the source code for you, no distro does this. Arch also has curated repositories. You don’t have to use AUR when you use Arch. It is just an additional option.
EOS has a community or “extra” repo right? Is there a way to request additions for it?
(Yes, I’m lazy and would rather have more skilled people vetting the packages I need. 
)
The extra repo is an Arch repo.
There is an endeavouros repo but we keep a minimal list of packages in it. Mostly the packages we make ourselves or things we need for the installer.
Ah that’s right…
Next question is… would it be beneficial to add a “community repo” such as one I described for EOS? Could make EOS even more noob-friendly. I know, I know… we wan’t people to be self-sufficient and learn Arch like the gods intended… But still. 
Maintaining packages takes effort and we are a small team. I can’t see us taking something like that on.
That’s a lot of work.
Again walking into a dangerous situation doesn’t mean that we must now change everything because someone no longer feels safe. Life is life either accept responsibility for ones OWN actions or continue blaming others for ones own failures. Sorry but I have to totally disagree with your entire stance on this. Again Arch is for the Proficient if that’s not you don’t use it. Again one must accept responsibility for the things they choose to use and they must determine if that use must be changed or ended.
I was going to say more, but really there’s no point. This says it all. and says it quite well.
I mentioned Debian not because it analyzes the source code, as you rightly pointed out, but because it has built a robust security infrastructure that goes against the idea that you need huge corporate budgets, financial resources comparable to those of Microsoft, or teams of lawyers to handle the legal side.
I can agree with you up to a point: we are absolutely responsible for our own choices. If I misconfigure my system or break something, that’s entirely on me.
But I think we just look at “personal responsibility” from two different perspectives here.
From my point of view, when an upstream project gets compromised, it is an infrastructure challenge rather than a user mistake. No matter how much we learn or how proficient we become, it is practically impossible to spot a hidden, sophisticated threat with the naked eye.
Don’t get me wrong: EndeavourOS is an excellent distro, and this forum is a fantastic, welcoming environment for learning. I truly appreciate the community here.
My intent isn’t to critique the DIY philosophy, but rather to look past the old “use at your own risk” disclaimers. The modern threat landscape is changing fast, and I believe discussing how infrastructure can better protect users is a conversation worth having, even among expert communities.
You do realize that’s only for the AUR, right? It doesn’t apply to the official repo packages, which are essentially the same as the repo packgaes in Debian, Fedora, Suse. etc.
Actually, because it’s so simple to review PKGBUILDs, AUR packages are overall more secure than using binary PPMs in Unbuntu.
My 2 cents.
Is it possible and feasible for AUR leaders to require Authentication of the ID of the AUR contributor?
Sure. Just like it’s possible and feasible for governments to require authenticated ID for people to access the internet. Privacy be damned.
Sure, but well, not always.
In the sense that: Upstream supply chain compromises haven’t just targeted the AUR; they can, and have, also targeted official repositories. A perfect example was the XZ Utils incident.
That’s precisely the point: when a threat occurs upstream, the package appears 100% official and clean in the distribution’s main repositories. This is why manual user vigilance or sole reliance on repository curation is no longer a complete solution in today’s threat landscape.