LLMs are the new hammer looking for nails, especially for a new group which were/are not coders/tinkerers.
IMO the vetting of PKGBUILDs could be made easier by encouraging maintainers to parametrize their URLs. Also a change of URLs or maintainer EMails can be checked with static code.
Yes, I think some new rules will need to be put in place - some LLM tools put in place to monitor the AUR and flag up changes for human review.
Itâll need to be done carefully to enable new maintainers (as now, theyâre all blocked).
Thereâs no need for LLMs. Itâs over complicated and there are simpler and more reliable ways to make checking PKGBUILD diffs easier.
Actually thatâs what theyâre already doing. There are far too many PKGBUILD up there for manual management. Itâs trivial to load up a small LLM to manage simple scanning tasks.
Having paru preinstalled is fine, using the AUR is always a personal risk. That being said does Cachy update also update AUR packages?
Because I recall that it does, perhaps letting users turn off the auto updater or even having it off by default would be useful since most people vet things once and might just want to get an update out of the way.
Itâs one thing to install software from an unofficial source(especially if you mainly only get developer supported AUR packages) but if the author changes itâs a risk many would rather avoid in their time saving update tool. I mean itâs not too much trouble to run pacman -Syu and flatpak updatebut itâs nice to be notified and not bother doing it myself 1~3 times a week.
Relevant here?
âUNIX was never designed to keep people from doing stupid things, because that policy would also keep them from doing clever things.â [Doug Gwyn]
It does, but it makes you read the update script. If you choose to NOT read the PKGBILD it does not update AUR packages. I think it is a totally reasonable approach and helps to guide the users to a develop a âmuscle memoryâ for doing this check.
AUR is not the problem, malicious actors are a problem. Just like with a lot of things on the Interwebs these days, take any non-official software install with a grain of salt and do you own due diligence when installing software, copy-pasting scripts, or taking advice from random YouTubers.
Back in the day, Manjaro was touted as being ânOOb friendlyâ⌠but this commentary changed when they realised just how much that was being misinterpreted.
The fact is that itâs built on Arch and AUR is not supported. Thereâs no way around thatâŚ
Similarly, Rally drivers donât use ABS.
Good analogy!
Removing paru will do little. Say a user wants to use a certain program, many git repos (if they have an Arch section) commonly have you pull from AUR. If paru by default wasnât there, said user would likely still install it to get said program. This really is not much different from the Windows side where someone googles a random program and just installs it without a second thought; all AUR does in the Linux world is consolidate this to make things a bit easier.
People avoiding AUR altogether as some sort of security measure is not the answer. They should be taught the basics of what to look for: check popularity, last update, is it orphaned, read the PKGBUILD etc. etc. At the end of the day, security is the responsibility of the user as cscs mentioned. Unless they stop being lazy and take it seriously, weâre just going to be right back here when something else happens.
If you explicitly install it, then itâs your responsibility.
If itâs already there, you can expect it to just workâŚ
Itâs a fundamental shift.
Well - yes it is. They have to accept then that they can only install from repositories, or possibly download packages to run from folders, or work out other complicated ways of installing their software.
Whatâs funny here is that you can often work out how to install something (I remember Plex-HTPC first installed via AUR by downloading the snap package, other stuff might pull in a deb or rpm, or just a basic archive) and see how itâs handled.
90% of the time the process is long winded and complicated, far more so than reading a PKGBUILD.
But for some people itâs just too much - those people are rather new and green, and my argument there is that theyâre not really ready for an Arch-based distribution.
The answer for them is, quite rightly, to consider their position, but also not to use the AUR.
Itâs not about being lazy - many people simply donât have the intelligence.
I disagree here; this is opening up a vector for exploitation because LLMs are not thinking beings, they are dumb bots who can only follow instructions. The most recent AUR attack switched tactics once detected to concatenate/obfuscate the malicious code in attempt to circumvent the LLM âscannersâ people were making, but these attempts were quickly spotted by Human Eyeballs 1.0
Youâll also be disapointed, then, that these very exploits were weeded out by AUR maintainers with the help of Google LLMâs they had locally installed for the task⌠Though the scanners are designed to hopefully find things that we didnât find, as long as we donât feel âsafeâ in the knowledge that they have our backsâŚ
Obviously youâre correct that simply reading and analysing the process every time we install, and again every time we update an AUR package is essential.
I think the idea of using an LLM to âkeep an eye openâ is more valid for AUR maintainers to get specific kinds of changes flagged for review, not as a shield.
I will never use nor condone LLMs. The world is better without them for so many reasons.
Back on topic, I donât think removing Paru makes any sense. The user assumes all risk. The user is also able to obliterate their system with rm -rf / but this should not cause the community to demand its removal.
This is an extreme opinion stated as fact⌠and it doesnât remotely address the many specific use cases where that is simply untrue, but also other specific cases where it is true.
rm is just a false equivalence.Try answering this question:
makedepends() or an unexpected source array change that a maintainer might miss?You canât apply this argument to the use of ârm -frâ with a * to remove all French language 
Preinstalling Paru means the AUR is now a core part of the system, just like pacman.
This, in my opinion, is where users are expecting Cachy to accept and take responsibility.
They shipped AUR as part of the distribution, so they must now take responsibility.
Thereâs a good reason why itâs not enabled, for example, in EOs, or Manjaro⌠and any question is first responded to with the sentence âManjaro does not support use of the AUR, you do so entirely at your own riskâ.
CachyOS repos undergo vetting, AUR undergoes nothing.
Paru should NOT be pre-installed, but itâs a good idea to have it in the repository.
Remove âBrainâ it is not used anymoreâŚ
Thanks for the heads up. I guess we shouldnât read too much into your posts if you just removed your brain⌠
@Cina is right.
Go the whole hog - the world would be better off without computers too.
Well done debunking my arguments.
You canât put that toothpaste back in the tube.