All of that wouldn’t have any effect if the aur helper mimics the model of pacman. Trust the maintainer, not the build script. By requiring users to review PKGBUILD every time it changes, it encourages laziness. But by requiring the review only once then trusting the maintainer, it helps a lot because the only way an attack can be done is directly attacking infrastructure (pushing malicious script bypassing the auth) or hacking the account (author turning malicious). Both of those are hard with a properly configured system or not worth it because it requires a long game (like those of xz attack)
Totally but I also want to point out that reviewing changes is a lot easier than the first review. Ideally it has just a couple of lines changes and they are just version changes most os the time. It also does not help the existence of “pacman for AUR” that just encourages all the bad behavior, they encourage installing a lot of AUR packages without thinking twice, update without checking and to trust it or think it is the same as the maintained main repos since I think most if not all AUR packages also work as a pacman frontend.
The user was never supposed to rely on a lot of AUR packages and if you do maybe you better of with a distro that does package what you need or that the software authors package for.
Sure reviewing changes is easy. But the problem is that it is still a review. You need to have an understanding of what exactly is being done and to account for any oddities that may or may not be because of the quirks of upstream. That’s why I mentioned that AUR trust models should be made like pacman for most helper. We trust the maintainer of Arch so why can’t we trust other people too? Take PPA, the trust model is exactly that. You trust the maintainer. At the very least make it an option that you can choose on first run
All of that wouldn’t have any effect if the aur helper mimics the model of pacman. Trust the maintainer, not the build script. By requiring users to review PKGBUILD every time it changes, it encourages laziness. But by requiring the review only once then trusting the maintainer, it helps a lot because the only way an attack can be done is directly attacking infrastructure (pushing malicious script bypassing the auth) or hacking the account (author turning malicious). Both of those are hard with a properly configured system or not worth it because it requires a long game (like those of xz attack)
Totally but I also want to point out that reviewing changes is a lot easier than the first review. Ideally it has just a couple of lines changes and they are just version changes most os the time. It also does not help the existence of “pacman for AUR” that just encourages all the bad behavior, they encourage installing a lot of AUR packages without thinking twice, update without checking and to trust it or think it is the same as the maintained main repos since I think most if not all AUR packages also work as a pacman frontend.
The user was never supposed to rely on a lot of AUR packages and if you do maybe you better of with a distro that does package what you need or that the software authors package for.
Sure reviewing changes is easy. But the problem is that it is still a review. You need to have an understanding of what exactly is being done and to account for any oddities that may or may not be because of the quirks of upstream. That’s why I mentioned that AUR trust models should be made like pacman for most helper. We trust the maintainer of Arch so why can’t we trust other people too? Take PPA, the trust model is exactly that. You trust the maintainer. At the very least make it an option that you can choose on first run