>And so we like have this thing called "orphaned packages"What's that?>An orphaned package is when the maintainer stops maintaining a package they submitted.Yeah, that happens. So you mark the package as orphaned and move on?>Yes! And also anyone who wants to maintain it can take over the package!Anyone? Like, literally anyone?>Yes! But the new maintainer has to submit under a new package name, right?>Nope! So a new maintainer can come in and take over a package that users are already using.>Yes!There must be some kind of verification process in place for this. >No, it's super easy! You just submit a form that gets automatically accepted!...
>>109065714yeah pretty fuckng stupid. I was wondering when they said someone oertook orphaned packages that surely there was some sort of vetting that took place.
>>109065714Literally just use fedora.
>>109065714Why would there be a verification process for adopting packages when the previous maintainer was never verified either? If you want packages from trusted maintainers, stick to official repos.
>>109065714I thought packages were signed with GPG and shit
>>109065828>Alice creates a package in 2018.>Alice maintains it for 8 years.>Thousands of users install it.>over those 8 years, Alice builds a reputation. users trust her updates because they've seen years of legitimate maintenance.then Alice leaves.>Bob takes over the package.>Bob may be completely trustworthy, but users have zero history with Bob. the trust that was built over 8 years belonged to Alice, not Bob.that's exactly why the second maintainer deserves more scrutiny than the first.when Alice first created the package, nobody was already trusting it. there was no established user base and no inherited reputation.when Bob takes over, he instantly inherits a package with thousands of existing users who may blindly install updates because they trust the package name and the history behind it.the risk isn't that Bob wasn't verified. the risk is that Bob inherits trust that he didn't earn.that's why ownership changes should be highly visible and why a package takeover should probably receive more scrutiny than the original package creation.
just use one of the wrappers that has claude inspect the pkgbuild
>>109065884It's gambler's fallacy From security perspective, Alice can be trying to do a supply chain rug pull, or trust-then-poison attackreputation doesn't matter
>>109065884I agree that the adoption mechanism needs scrutiny, and notifying users of a package changing hands could help prevent another mass takeover campaign. But it's not foolproof, Bob could just take over Alice's package, release a legit update, then some time later push a malicious update. When it comes to the AUR, you don't build trust, you build complacency.
>>109065940i wasn't saying Alice is safe simply because she's been maintaining the package for 8 years. i agree that a long-standing maintainer could still perform a trust-then-poison attack.my point was that a maintainer change is a known, observable event that users can be notified about.a trusted maintainer going rogue is certainly a risk, but there isn't necessarily an obvious event beforehand that can be flagged to users.when ownership of a package changes, however, we know that the trust relationship has changed. whether the new maintainer is trustworthy or not is beside the point. the change itself is information users may want to consider before installing future updates.
>install packages from the "gay, you are">wtf why did I get computer aids???Only tinkertroons have this problem, actual productivity programs have flatpaks, and all the important shit are hosted on the main reposAnd there's always the option to build yourself
