I’m not entirely sure I agree, I think the issue is with default settings.
Like you could use both yay and paru to diff the PKGBUILD of the most recent updat and then read it, and then approve each. And I think that’s pretty helpful. But you could also just blindly accept the update with the right config or flag and that is not a good practice.
Yeah, use and promote aurto instead. They require you to trust the maintainer and would remove the package from the local repo if the maintainer is changed
Well, it is just like a distro maintainer account anyway. If the maintainer account is compromised then gg for the whole distro. That’s what happens with other supply chain attacks as well and yes, I do think we need a way to fix that without compromising on ease of usability
Yes, and that is no different than distro maintainer that maintains the infrastructure and package. Anyone can volunteer. That’s how xz is compromised. The point is that aurto trust models mimic those of other package managers. Trusting the authors implicitly trust the code. The only other special things from distro maintainer is their PGP signatures are required to perform release on the main repo. This is better because as I stated earlier, reviewing PKGBUILDS would encourage people to just skip it. Not everyone has the time for that. But when a maintainer changes? Aurto removes the package for you to perform that first trust again on the new maintainer. This is no different than if you update the arch keyring just more manual
I know where you’re coming from when you say they are different. But I disagree on that because at the end of the day you’re still trusting other people would not act maliciously or get their account compromised. The selection process doesn’t make it any more special as demonstrated by xz in my example.
Anyone can be an AUR submitter and maintainer. Act in good faith and never become an Arch maintainer. Someone can be an Arch maintainer and be good for a few years then something happened and their account got hacked or bad blood made them act rashly.
That’s precisely what I mean when I equate AUR maintainer to the distro maintainer. To the package management system, they are both trusted. Not in the sense of how special they are or how strongly you can trust one but not the other.
I’m not entirely sure I agree, I think the issue is with default settings.
Like you could use both yay and paru to diff the PKGBUILD of the most recent updat and then read it, and then approve each. And I think that’s pretty helpful. But you could also just blindly accept the update with the right config or flag and that is not a good practice.
Yeah, use and promote
aurtoinstead. They require you to trust the maintainer and would remove the package from the local repo if the maintainer is changedI’m not sure if loosing the maintainer is to only thing we should be going off of here, but I like the name.
Well, it is just like a distro maintainer account anyway. If the maintainer account is compromised then gg for the whole distro. That’s what happens with other supply chain attacks as well and yes, I do think we need a way to fix that without compromising on ease of usability
We arnt talking about a distro maintainer, but an aur package maintainer, which can be anyone.
Yes, and that is no different than distro maintainer that maintains the infrastructure and package. Anyone can volunteer. That’s how xz is compromised. The point is that aurto trust models mimic those of other package managers. Trusting the authors implicitly trust the code. The only other special things from distro maintainer is their PGP signatures are required to perform release on the main repo. This is better because as I stated earlier, reviewing PKGBUILDS would encourage people to just skip it. Not everyone has the time for that. But when a maintainer changes? Aurto removes the package for you to perform that first trust again on the new maintainer. This is no different than if you update the arch keyring just more manual
No, an aur maintainer is not the same a distro maintainer.
But I do agree it would be good to atleast stop and evaluate when the maintainer changes or a package looses the maintainer at a minimum.
I know where you’re coming from when you say they are different. But I disagree on that because at the end of the day you’re still trusting other people would not act maliciously or get their account compromised. The selection process doesn’t make it any more special as demonstrated by xz in my example.
Anyone can be an AUR submitter and maintainer. Act in good faith and never become an Arch maintainer. Someone can be an Arch maintainer and be good for a few years then something happened and their account got hacked or bad blood made them act rashly.
That’s precisely what I mean when I equate AUR maintainer to the distro maintainer. To the package management system, they are both trusted. Not in the sense of how special they are or how strongly you can trust one but not the other.