Hacker News new | ask | show | jobs
by kcyb 4 days ago
As an arch user, I would always skim the PKGBUILD file of AUR packages to see if they install the software they claim to install from official sources and if there's something obviously fishy.
3 comments

The BSDs prevent this by never having allowed random jamokes to upload Makefiles into the ports system.
Yeah, I've prevented this locally too by never building such a platform in the first place, always the best solution!

Jokes aside and just in case, you do realize ports and AUR have two very different models? Ports is more similar to the official Arch repositories, which obviously doesn't suffer from the same problem, and AFAIK, there is no BSD-equivalent of AUR.

BSD is cool and useful for lots of reasons, but comparisons based on misunderstandings helps no one :)

There is pkgsrc-wip which is similar but run by one person who does at least some checking up on new users. AUR is just gigantic in comparison; pkgsrc-wip has about as many total packages as AUR has updated in the past week.

https://www.pkgsrc.org/wip/

But why check the user instead of the actual code? That's like asking people to checking the GitHub user before they install a program from GitHub, instead of the program itself! Ultimately, the PKGBUILD is the only thing that matters here, not the author or how many others reviewed it.
That isn't what I ment, I should have said that the person who runs pkgsrc-wip helps submitters get the package correct (which can be more challenging than PKGBUILD since it is a more strict system and unless it is a Linux only package is more likely to need patches). Thinking about it more it isn't really the same as AUR since as I understand it packages without issues are likely to get into pkgsrc proper in most cases so it is mostly WIP as the name suggests (although not entirely as I recall, at least last time I used it). So you might be correct that there isn't really anything similar in the BSD world.
In this case even if you skimmed it you likely would have missed it since the malicious change was adding a new dependency called "atomic-lockfile".
I'd be surprised if you did it as a Debian user!