Comment by micaeked
9 hours ago
Both already do that. The AUR stuff is more of a policy issue and unmatched expectations, unrelated to llms imo
9 hours ago
Both already do that. The AUR stuff is more of a policy issue and unmatched expectations, unrelated to llms imo
> The AUR stuff is more of a policy issue
Yes. This has happened before, a few times, before LLMs were even a thing. Via the same mechanism as well (someone else adopting an orphaned package). The big one I'm remembering was in 2018.
Outside of that mechanism though, anyone who uses the AUR regularly knowingly accepts this kind of risk. It's why I'm not a huge fan of distros (like Cachy, Endevaor, etc) that take Arch and package it up in a one-click easy installer with preinstalled AUR helpers. Cachy even uses the chaotic AUR too (auto build service for AUR packages to serve binaries). I like CachyOS, but good lord don't put in Yay + the AUR by default.
The ability for any registered user to just adopt an existing orphaned package is a problem (these attacks will always exist, but least force a fork & resubmission under a different name), and so is the use of automated AUR helpers that don't show PKGBUILD diffs.
The hygiene required to use the AUR is no different than the hygiene required to use pip, npm, cargo, etc. Anyone just blindly trusting user submitted packages and code from the internet is not operating with security in mind.
Adopt a policy of zero trust from any arbitrary code you download from the internet.
Well, both give you 6 months of access. Out of interest I applied some time ago and (despite maintaining a few fairly important OSS projects) never got a response from them. Of the other maintainers I know, it seems to me that they decide who to give access to fairly randomly.
Wonder how dependent it is on social following.