Comment by delecti
7 hours ago
That title had me worried, but the reality seems quite reasonable.
I assumed the goal was to reduce usage of AUR, they've actually remove the ability to adopt (take ownership of) orphaned packages. I'm sure there are legitimate uses of that functionality, but it also seems like a pretty big avenue for abuse.
I've used it (not for abuse). It's simply volunteering to maintain the package after previous maintainer(s) have explicitly disowned it, knowing they no longer have time for it or don't care because they stopped using it, etc.
Problem is that there is no KYC process before someone can adopt any orphaned package
Yeah, I don't disagree there should be more of a barrier, I remember being surprised I could just adopt things. Just explaining the intended use.
There's also no KYC process for creating one.
IMO allowing package adoption makes sense in the responsible/intended use-case: AUR packages aren’t trusted, you have to read the PKGBUILD anyway, so the reputation of the contributor doesn’t matter. Removing adoption is admitting that there’s no way to prevent some users from blindly trusting a PKGBUILD.
Which is probably the best choice, unfortunately.
> I'm sure there are legitimate uses of that functionality
To avoid package name pollution, e.g. having package foo, foo-newpackage, foo-newpackage-updated, etc. each by a new maintainer as the priors get abandoned.
With a bit more structure, you could change that to: every package in AUR is actually registered as foo/maintainer under the hood, and installing the package without maintainer name pins it to the currently active version. Package adoption can then be formalized as a new maintainer publishing their own version of the package, and users of an already-installed package need to issue an explicit command to switch over to the new maintainer's version.
Or, have actual user repos like a normal distro.
2 replies →
Yeah, the security problems with unilateral adoption of orphaned packages by unprivileged users are fundamental and unfixable; the only remedy is to remove the feature. Whether it has legitimate use cases (which it sounds like it does) is irrelevant. I'm not sure why it took them so long to realize this and act accordingly, but I'm glad they now have.