The issue with the AUR is that its design and the way package maintainership works puts users at undue risk compared to many other "user" repositories. This happens because so many useful packages are only available in the AUR to begin with, but also because the mechanism for taking over an orphaned package is just simply too open for exploitation.
I don't have all the answers. I hope people will consider Nixpkgs as a powerful model: even though it has many thousands of PRs unmerged at any given time and requires substantial effort, it still operates at an absurd scale and yet has a higher bar to infiltration with malware, both due to build sandboxing and due to the review process. Whereas AUR maintainership is mostly handled individually per-package, anyone can submit changes to a Nixpkgs and try to get it reviewed, even if the maintainer of an individual package is long gone (though we usually give maintainers a week or so to take a look at a PR even once it has been reviewed.) This entirely gets rid of both the need and incentive to have a process to replace an orphaned package's maintainer: writing yourself in as the maintainer mostly just signs you up to get pinged for issues and PRs, it doesn't grant you special permissions to bypass the normal review process.
A giant monorepo of PKGBUILDs with a similar maintainership model plus makepkg sandboxing would be fantastic. makepkg sandboxing would be nice just for ensuring that packages correctly declare their dependencies.
I think the sandboxing thing has a better shot at actually happening, since redesigning the entire AUR around a completely different model is probably an unreasonable leap. That'd still be a pretty good improvement, though.
Comments
The issue with the AUR is that its design and the way package maintainership works puts users at undue risk compared to many other "user" repositories. This happens because so many useful packages are only available in the AUR to begin with, but also because the mechanism for taking over an orphaned package is just simply too open for exploitation.
I don't have all the answers. I hope people will consider Nixpkgs as a powerful model: even though it has many thousands of PRs unmerged at any given time and requires substantial effort, it still operates at an absurd scale and yet has a higher bar to infiltration with malware, both due to build sandboxing and due to the review process. Whereas AUR maintainership is mostly handled individually per-package, anyone can submit changes to a Nixpkgs and try to get it reviewed, even if the maintainer of an individual package is long gone (though we usually give maintainers a week or so to take a look at a PR even once it has been reviewed.) This entirely gets rid of both the need and incentive to have a process to replace an orphaned package's maintainer: writing yourself in as the maintainer mostly just signs you up to get pinged for issues and PRs, it doesn't grant you special permissions to bypass the normal review process.
A giant monorepo of PKGBUILDs with a similar maintainership model plus makepkg sandboxing would be fantastic. makepkg sandboxing would be nice just for ensuring that packages correctly declare their dependencies.
I think the sandboxing thing has a better shot at actually happening, since redesigning the entire AUR around a completely different model is probably an unreasonable leap. That'd still be a pretty good improvement, though.