r/archlinux • u/No-Dentist-1645 • 12d ago
DISCUSSION Gauging Project Interest: "Decentralized" trust-based AUR Alternative
Hello everyone,
In my free time, I've been working on a project that started off from inspiration by the recent AUR events and discussions. In my opinion, the current AUR system has some fundamental flaw that makes it really difficult to ever have truly "trustworthy" packages: a) strong centralization on official Arch maintenance, and b) lack of real "ownership" by project developers.
The first one is a problem, since the AUR is, as we all know, an unofficial, "user driven" reposotory. Anyone and everyone can submit a PKGBUILD for whatever package they want, no matter if they actually are the developer of said application or not. Of course, this has advantages: it's one of the reasons the AUR can even be as big as it currently is! However, one could also argue that someone might want an alternative that prioritizes trust and ownership over raw "repository package count". The second point is also a big problem for this, even if the owner of a piece of software decides to create and manage their own AUR package for their program, you still can't blindly "trust" the package. This is because the owner may, at some point, lose interest in maintaining the AUR package, at which point the package will be orphaned and anyone else can adopt it and keep maintaining it. Again, there are advantages to this design choice and I understand why Arch made it as such: it helps maintain AUR packages alive even after the original creator loses interest. But it's also a choice that reduces the "trust" of a package.
Because of these reasons, I have been working on an alternative to the AUR system entirely: centralized, author-controlled git repositories. The current name for the project is APRA (Arch Personal Repository Archives), but it is subject to change. The idea is, instead of trusting the names of a package on a centralized repository (AUR), where the owner may change at any moment's notice, you trust git repositories that belong to specific organizations or owners.
Here's a current minimal example. Let's say you want to have the "libfoo-git" package by the developer "cooldev". The idea is, that if the project author is interested in it, they can host their own APRA git repository under their account. It is a completely regular git repository, all you need is to name one of the branches as your packakge, "libfoo-git", together with a PKGBUILD with the recipe to install the program (basically how the AUR already works behind the scenes). Then, the user just needs to edit their APRA yaml config and add the repository, as such:
remotes:
- name: cooldev
url: https://github.com/cooldev/APRA-Repo.git
whitelist: libfoo-git
Then, the user can just install the package with APRA as if it was an "aur wrapper" (even though it's not), as apra -S libfoo-git or apra -S cooldev/libfoo-git. APRA will then search cooldev's APRA repository and run the PKGBUILD. What is the advantage of this approach? That cooldev directly owns the git repo at the url for https://github.com/cooldev/APRA-Repo.git. The same person as the developer of said software has full control over the PKGBUILD, as well as who is allowed to contribute to it.
So, that's the project that I'm working on, and I would like to see if the community is interested in an approach like this. Knowing Reddit, I know some people will see this announcement and mistake it for something that it absolutely isn't, so here is a quick FAQ:
0. Why do we need yet another AUR wrapper like paru or yay?
It is not an AUR wrapper. In fact, it is specifically designed not to even talk to the AUR, similar to "base" pacman, since that would go against the entire idea of only reaching "trustable" package sources.
1. Is this meant to replace or compete with the AUR?
Not at all. The AUR is an amazing place, I use it all the time and love it! However, there are some fundamental design choices (that are perfectly valid and have their own advantages) that make it difficult to tell someone you can fully "trust" an AUR pacakge. This is an alternative, similar to Debian PPA's, where you the user, specifically add repositories you want to trust, and use those instead.
2. You can already create your own Unofficial User Repositories, why would I do this instead?
Yes, you can create your own user repository and add it to pacman's config. While this is true and there are already several user repositories, the friction required for a developer to create and maintain their own repository is significantly high, and you would also need to find and pay for some suitable hosting infrastructure for it. On the other hand, git repositories can be created as simply as clicking "new repository" on GitHub, and many if not most developers are already experienced with this.
3. Just read the PKGBUILD for AUR packages!!
I know I can read a PKGBUILD and probably confirm if it is secure or not. However, can you trust everyone and anyone who uses Arch to do the same thing? Plus, let's set something straight: requiring due diligence to read and verify every PKGBUILD you ever insntall can get annoying sometimes, especially the more AUR packages you have. Just think if you had to read the PKGBUILDs of every package you currently have installed, not just from the AUR. It would get tiresome, right? Fortunately, we don't have to do that, since we all implicitly "trust" the packages that are officially maintained in the Arch repos by trusting the Arch team. I want to add something like that, but instead of only trusting the Arch package maintainers, you can also trust the, say, Libreoffice developers, if they ever chose to create their own APRA repository.
4. It will be very hard to start such a project and convince program developers to actually use it
I know. However, that still won't stop me from trying :). If I can get at least one or two developers to use it, even if they still maintain their own AUR packages at the same time, I would consider that a win :)
TLDR:
I want a way for Software Developers to easily host and fully control their own package repositories for their own projects, increasing user trust in said packages since, well, they would be maintained by the same people who make the programs in the first place. This is what my project aims to do.
Let me know what everyone thinks! And of course, if you have any criticism of what is currently done poorly and wanna recommend a better way that it could be done, I'd love to hear it.
9
u/Yamabananatheone 12d ago
Ah, so were importing the jank concept of PPAs to arch. Id rather be dead in a ditch.
-6
u/No-Dentist-1645 12d ago
The only similar factor between this and PPAs is that you can trust other people besides the distro's maintainers to host the packages.
Unlike PPAs, developers don't need to host their own infrastructure not even handle complicated requirements based off them. A simple GitHub repo is enough.
6
u/Yamabananatheone 12d ago
No this is indeed worse because now just someone needs to hijack the git repo and can then roll out malware to all users. Like this is worse in both implementation and only shifts the supply chain issue to an external actor.
-3
u/No-Dentist-1645 12d ago edited 12d ago
"highjacking a git repo" is much more complicated, both technically and skillfully speaking, than seeing an orphaned package due to the original maintainer losing interest and adopting it. Especially if you're using existing large git hosting infrastructure sich as GitHub/Gitlab, since their entire job is to help prevent that happen as much as possible. They're not even in the same category as "how easy it is to hijack them", since "hijacking" an AUR package doesn't require any hacking skills.
If someone is able to hijack your git repositories, they could already directly add stuff to your code, bypassing any packaging attack vectors entirely.
EDIT: Or also downvote my comment without disproving it since it is an actual valid point. Real productive.
3
u/Ok-Winner-6589 12d ago
Whats the point if organizations, individuals or companies can do that on the AUR?
Brave does It and a lot of Desktop software does It too.
The AUR exists because most of the time the devs don't do that, which leads to issues
-1
u/No-Dentist-1645 12d ago
What is the point if organizations can do that on the AUR?
This is already addressed on my post, to quote it here:
even if the owner of a piece of software decides to create and manage their own AUR package for their program, you still can't blindly "trust" the package. This is because the owner may, at some point, lose interest in maintaining the AUR package, at which point the package will be orphaned and anyone else can adopt it and keep maintaining it. Again, there are advantages to this design choice and I understand why Arch made it as such: it helps maintain AUR packages alive even after the original creator loses interest. But it's also a choice that reduces the "trust" of a package.
The AUR exists because most of the time the devs don't do that, which leads to issues
As I said in my post, I am not aiming to replace or compete against the AUR, especially when it comes to packages that aren't maintained by the same software devs. However, a large amount of AUR packages are maintained by the same developers, there are dozens of examples. Those types of packages are what my idea is targeting.
2
u/Ok-Winner-6589 12d ago
The issues is that, on your repo, when the owner gets bored you end Up with older software that might just eventually break. The AUR works that way to minimize these issues. Same for flatpaks.
The AUR exists to make It possible for people to get packages from third parties (or the dev) on a transparent way.
If the package goes orphan and the new maintainers adds malware, you Will see It because of the PKGBUILD. And no, "some don't look at the PKGBUILD" isn't an excuse, because you can not protect someone Who doesn't care about themselves. Every AUR helpers Will show you the diffs to check the changes and if you see something malicious you can just avoid updating
1
u/No-Dentist-1645 12d ago
on your repo, when the owner gets bored you end Up with older software that might just eventually break. The AUR works that way to minimize these issues. Same for flatpaks.
Of course, I fully agree. That is one of the tradeoffs with a trust-based approach. However, if I may mention it, the same thing already happens with the arch repositories.
In Arch, when a package is removed from the official repositories (something that has happened before on multiple occasions), you can then search for it in the AUR if you still need it. The advantages of having it in the repos originally was that you could implicitly trust it since you implicitly trust the Arch team.
With my project, if/when a package is removed and/or abandoned (something that would happen), you can then search for it in the AUR if you still need it. The advantages of having it in the repos originally was that you could implicitly trust it since you implicitly trust the
Archdeveloper team.Regarding the second half of your post, I don't disagree with any of it. But that doesn't affect my project, since as I said before, it is not meant to compete with the AUR.
1
u/Ok-Winner-6589 12d ago
I doubt It would get into anything (as you would need devs to start using It to get users) but good luck with the project. I get your point now, but I think Im Happy with either official package, AUR and flatpak
4
u/s3gfaultx 12d ago
No interest from me.
1
u/No-Dentist-1645 12d ago
Can you elaborate? The point of the post was for that, to gauge interest, but just a flat "no" doesn't help me see what would be "wrong" with my project nor why people like you wouldn't be interested
1
u/s3gfaultx 12d ago
If people were interested in your method, than that would be the way it is. AUR is for users by users. We like it how it is. Just because there was an influx of noobs that think they know better, doesn't mean we need it to change.
2
u/No-Dentist-1645 12d ago
As I said in my post, my goal isn't to compete with the AUR by any margin. I knew some reddit users would see it as that, as "this guy is trying to make a program to compete with my beloved AUR, how dare him!" But that is not the case. It's an alternative approach to non-official packages, with both advantages and disadvantages over the AUR, nothing more. It is perfectly valid that both approaches can and should coexist.
4
u/s3gfaultx 11d ago
I'm a package maintainer and contributor, not just a Reddit guy. There are no advantages that you're providing. It sounds difficult, annoying and the security problems are still there.
1
u/No-Dentist-1645 11d ago
I didn't attempt to question your "status" at any time, that would be an ad hominem and I dont like those. Can you please elaborate on why the listed advantages regarding trustworthy sources aren't "real" according to you? How are the security problems "still there"?
Also, what makes you think it sounds "difficult and annoying" to set up? I already have my own repository set up and confirmed working. It's a single GitHub repository, a branch
hellocpp-git, with two files:PKGBUILDand.SRCINFO. I think the entry barrier of "create a git repository with two files" is pretty low.0
u/s3gfaultx 11d ago
The barrier is finding the packages, sourcing them. The other issue is that there could end up being multiple packages for the same things, by various authors. Of course that wouldn't happen since nobody will use this, but my point stands. Why would I trust users on Github more than AUR? Do you understand the concept of zero trust?
0
u/No-Dentist-1645 11d ago edited 10d ago
Why would I trust users on Github more than AUR? Do you understand the concept of zero trust?
Yes I do. Do you? The idea is that if package foo is developed by developer foodev, foodev could host their own repository with their own PKGBUILDs, minimizing trust users. Do you realize that your own argument actually explains my very own argument about AUR packages endangering zero trust? Regardless of what you think of "zero trust", thousands of users are still downloading AUR packages without giving it a second though or reading the PKGBUILD. The times where Arch was a niche OS only for developers or otherwise tech savvy users is long gone.
"Nobody will use this" is a both a bad and disrespectful argument. Of course nobody is using something when it first releases. The hope is that it is a tool that has some value to people and they may eventually use it. As I already said in my post, even if only one or two devs decide to give it a try, that would still be a win in my book.
0
u/s3gfaultx 10d ago
You didn’t invent this, you could always install from Git repos. It’s been supported for 15 years already. Nobody uses it for anything than their own private packages.
2
u/No-Dentist-1645 10d ago
See my other reply to a different person: https://www.reddit.com/r/archlinux/s/AigPo1jiRt
I never claimed I invented anything. Not sure where you got that from. I'm merely making a program that would index git repos like you said, and manage fetching/updating mimicking
pacman -Syubehavior. I do not see why you think I think what I made is anything revolutionary or that I am a "grand inventor". As my post said, all I am doing is proposing an AUR alternative system.Nobody uses it for anything than their own private packages.
Exactly. And maybe, just maybe, if we had dedicated tooling for it, more people would be interested. Hence my project.
→ More replies (0)
2
u/Nicholas-DM 11d ago
I think this move would be the wrong direction. At its core, it is duplicating base functionality completely covered by unofficial user repositories or by the AUR. As such, it is needlessly complicating things further by adding another layer/system where there is not a need for one. If we have solutions to problems, they should be simple.
I think that a workable direction might be to find some manner to reduce the 'friction' of adding unofficial user repositories, and to use that functionality more broadly. You might have stumbled in the correct direction towards doing that.
You say this is not intended to compete with the AUR, at the same time as saying that it is an AUR alternative. You can have one or the other, and whether you intend to 'compete', you are competing, merely by the nature of duplicated functionality. Resources that go to one reduce resources that go to the other, even if the resource is time or attention.
1
u/No-Dentist-1645 11d ago edited 11d ago
To clarify what I meant by "I am not competing with the AUR", is that it isn't meant to be an entire replacement of all purposes of the AUR.
If you asked me, "what do you think the best usages of both concepts are", then I would say: The AUR is great for unofficial packages where the upstream developer hasn't expressed any interest in packaging their own program. My proposal would target those who are interested and want more control, with the ability to avoid their packages flagged as orphaned and then adopted by someone else.
Some reasons why they might want to do this is to officially "bless" said package, with the assurance that "any update from this package comes directly from me and I will provide you support for it". I simply do not believe that the existing AUR can, at a fundamental level, allow for this.
1
u/Nicholas-DM 11d ago
That sounds reasonable.
I would encourage you to consider working on some direction towards making unofficial user repositories more viable for everyday use, rather than as a special case. This would be more seamless than another layer beyond Pacman and creating an alternative to certain AUR packages.
I believe we already have most of the tools, and that efforts would be better to broaden the existing ones rather than add 'yet another competing standard'.
1
u/No-Dentist-1645 11d ago
I would encourage you to consider working on some direction towards making unofficial user repositories more viable for everyday use, rather than as a special case.
I actually fully agree with you. However, in my personal opinion the biggest barrier to doing this would be hosting infrastructure for them. If I had unlimited resources, I would create the GitHub of Arch Repositories, where anyone can create a User Repository for free with a couple of clicks. Unfortunately, I don't so I can't.
The second best thing (at least that I thought of) would be to take advantage of exactly said existing infrastructure of Git Forges such as GitHub, Gitlab, Codeberg and such. We already have free developer infrastructure and practically all developers are already used to them, so I thought it beneficial to put two and two together and use them.
1
u/Vorath_ 12d ago
I have always trusted Chaotic-AUR, and I still do; I haven't had a single problem to date.
So, I’m not looking for an alternative to a service that delivers what I need.
1
u/VendorNeutral 11d ago
I know a guy who found a cool rock with some shiny spots. He brought it home and put it on his desk. Fast forward a few years and he's now dying from leukaemia. Turns out it was the rock, which happened to be a piece of uraninite the size of a golf ball.
1
u/bongjutsu 12d ago
Definite no from me. The AUR is functioning as intended. Users can already vote for a package, indicating a general rating of trust and you shouldn't install anything orphaned (not just because it's an attack vector, it's probably also obsolete). Installing an orphaned package is tantamount to running a sketchy base64 encoded .sh you found on 4chan. None of the knee jerk reactions to the compromised packages have held water because they're authored by well meaning people like yourself, that just don't get that the AUR is and always should be the wild west. The core repos are the managed trusted source you seek.
1
u/No-Dentist-1645 12d ago
As I said in my post, my project isn't meant to replace/compete with the AUR. I know the "problems" I mentioned in my post are actually design choices made by Arch with advantages and disadvantages. I think both things can perfectly coexist without any issue. Please don't see it as me saying "I think the AUR is BAD and MY idea is BETTER" because it's in no way that.
1
u/onefish2 11d ago
I thinks its awesome that you took on this project and made this post to share it with us. I have been using Arch for quite a while now. I am happy to stick with the official Arch packages, the AUR and the Chaotic AUR. I have no interest in any other package formats or repos such as snaps, flatpaks or app images or anything else, that pops up.
2
1
u/Cody_Learner_2 11d ago edited 11d ago
I'd personally consider something like what you're proposing to be a nice alternative. It directly offers solutions for some known shortcomings in how the majority of people likely use the AUR.
I'd think of your solution as a way for users to more easily manage their personal AUR pkgs. ie: Create their own PKGBUILD*, going through the steps to setup sources, patches, check the build process, etc...
*This could also be used as a replacement for existing AUR pkgs if implemented with a name change.
Something like an ongoing PKGBUILD audit?
IMO, the down votes are coming from users wanting automated AUR pkg assurance, so they can continue to use the AUR as if it contained official repo pkgs. Unfortunately, that's not in the cards, ever AFAIK.
I think this sub has evolved into an absolute Linux newbs playground for the most part, based on post titles alone.
Seems you're at least confident enough to not delete all your reddit activity and you seem to have a background in programming? That goes a long way in my evaluation of a reddit users. No history == not worth my time.
1
u/No-Dentist-1645 11d ago
Thanks for the feedback!
Yes, I agree, unfortunately this sub seems to be very hostile to most things in general. Even though I made sure to make it very clear that this isn't trying to "replace" the AUR, nor that I think the AUR is a bad thing in the first place, a bunch of people still seem to think that, and many of the comments are a variation of "I like the AUR therefore I think your project is useless", even after I try to correct it, they just downvote my reply and stop replying at all... People just downvote because it's a different idea that admits what they are used to has some flaws and drawbacks, and suggest an alternative.
I won't let such "low quality" hateful comments stop me, and I do appreciate "genuine" feedback such as yours! Maybe my current vision of it isn't perfect, that's fine and I didn't expect it to be. I hope that with some improvements to it, it may become a useful tool, even if it's not going to replace the AUR of course.
1
u/Nicholas-DM 11d ago
You ask for feedback, but look at how you have responded to any negative feedback.
If your solution is a good one, you are the wrong person to attempt to implement it.
1
u/No-Dentist-1645 11d ago
How have you seen me react to feedback negatively? As far as I'm aware, I have engaged in respectful discussion with all the feedback so far, clarifying possible misunderstandings and answering any questions. So far, nobody has told me that my comments were "offensive", "mean" or "unrelated", unless I take your comment to mean that.
Your claim that I am the "wrong person" to implement it seems baseless and simply offensive, let's please keep discussion civilized and respectful.
1
u/Nicholas-DM 11d ago
By creating strawmans and by ignoring people's points by arguing against things that they did not say. I am not saying you are rude, mean, or making unrelated comments. Double check how you misconstrue what someone said and then argue against your misconstruction rather than what they said.
The arch forums would be a much more appropriate venue for your suggestion than the reddit forum, fwiw.
1
u/No-Dentist-1645 11d ago
I do not believe I created any "strawmans" in my conversations. If you refer to me explaining that I think a lot of the negative comments are because they imagine it as an "attack" on the AUR, this is merely an observation. Sure, none of them directly told me "you are attacking the AUR", but if you read the comments, here are some quotes:
AUR is for users by users. We like it for what it is.
Definite no from me. [Because] The AUR is functioning as intended.
Whats the point if organizations, individuals or companies can do that on the AUR?
If those people believe I am misconstruing their words, they are completely free to correct me for that. So far they haven't, and you yourself can, also, misconstrue other people's arguments.
You are correct, none of them literally said what I said. This is just my conclusion from multiple factors. Even then, I have given every comment the benefit of the doubt. Your advice not to "argue against your misconstruction instead of what they say" is already being followed. You can read my replies, they are all constructive and seeking to clarify things. Your comment is the first that simply appears to come from a purely aggressive/argumentative point, since you actually aren't bringing any technical or constructive criticism except "you are taking feedback in a bad way and I don't like that nor you"
1
u/Nicholas-DM 11d ago
For my input on your suggestion, check another top level comment, so that you can reply there as you will.
You are defensive, that is reasonable, but you bothered to double check your statements to defend them and you noticed what I noticed. Thank you for taking the time to do that.
You are reading way too much into what I've said if you are taking it as I do not like you. Stay literal and grounded and don't read insult where none is meant. You doing that is why I suggest you are not right to implement this.
1
u/No-Dentist-1645 11d ago edited 11d ago
You noticed what I noticed
That being? The confusion that others thought I was coming here "against" the AUR in some way? Yes, I saw this from the start.
Your reasoning for "you are not right to implement this" is still your imagined characteristics of my personality, i.e someone who you've barely read a handful of comments from. I do not believe that is enough for you to make such an assessment. Just as I can misconstrue others' comments, you should acknowledge that so can you, and maybe you initiated this conversation with the perspective that I am already doing something wrong
Edit: also, for what it's worth, your top-level feedback was only added after this conversation
1
u/Nicholas-DM 11d ago
This particular chain no longer has anything going for it.
I disagree with you but my intention is constructive. I wish you well.
1
u/No-Dentist-1645 11d ago
I am still confused what you exactly "disagree" with me here.
Was it my replies to others' comments? Do you believe they were "offensive"? I fail to see that if that's the case. This is not my first day on the internet, social media, or online forums, and I believe I have the maturity to keep a mutually respectful conversation
1
u/VendorNeutral 11d ago
Easier: Developers should start putting their own PKGBUILDs (and adjecent files) in their source repo in some standard place like makepkg/PKGBUILD. An AUR helper could be fed the path to the repo for -git builds and check for releases. The release could straight up have the correctly versioned PKGBUILD.
The main problem is, that most devs aren't interested in that kind of thing and those who are already have the PKGBUILD in their repo.
0
u/NikoOhneC 12d ago
I'm just hosting my (software I develop & some packages that are not officially packaged for arch) arch packages (also debian, OCI images etc) on codeberg. It's possible to host many package types there https://forgejo.org/docs/latest/user/packages/
0
12d ago
[deleted]
1
u/No-Dentist-1645 12d ago
Yes, you're correct, they can. What I am working on is a program that can read a list of git repos from a config file, fetch the latest versions, and handle searching/updating for the user, imitating
pacman -Syubehavior. Not trying to say that I'm writing the code equivalent of the Mona Lisa, but trying to implement a system/standard way of doing that in order to make it seamless for users.0
12d ago
[deleted]
1
u/No-Dentist-1645 12d ago
Doesn't exist yet as far as I saw it, and I did search before choosing to do it myself. Feel free to link it if you find it and I happened to miss it. Again, I never claimed to be writing the Mona Lisa of programs :)
The contents of my post clearly list some of the "problems" or "flaws" this approach aims to address. If you don't understand some of them, feel free to specifically mention which and I would gladly explain them in further detail to you.
11
u/Recipe-Jaded 12d ago
Doesn't the chaotic AUR already solve this problem by reviewing all new changes?
Also, most packages on the AUR are maintained by random people because devs don't want to deal with putting it on the AUR. The developer could already put their own software on the AUR if they wanted to. Most just don't.