Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

That is absolutely the wrong takeaway. The correct takeaway is that supply chain attacks and spam are real threats, and that these metrics can be gamed by malicious actors.

The work in cloning a repo is negligible, and the requirement of work is not a security design guarantee in github. The actual cost of liking projects is network, malicious actors need to create fake accounts, waste IP addresses and ip blocks in the process. Whether you are cloning or liking is just the last mile.

To me the takeaway is not to trust a project based on it's github metrics, and by extension not to trust projects just because they are linked and liked in hacker news for example. And to be wary of how I introduce dependencies into my projects.

Not just because of strictly malicious dependencies, but also because of trash dependencies that don't add value.



> because of trash dependencies that don't add value

And at best, will still need maintenance in the future. One of the top lessons I preach to juniors.


I like the idea of granular permissions for libraries. When you include a dependency you whitelist permissions it gets. Package managers could automate this if the language supports it. But making it about permissions instead of metrics .akes it not arbitrary. This library gets no filesystem access, that one gets no network access. This one runs build time system commands... Austral is the only language I know of that supports such a thing. While it might be possible to bolt it on to rust, I think it would take so much rework to make it infeasible.


For all speculation around supply chain attacks with fake Github stars, the article says:

"our study does not find any evidence of fake stars being used for social engineering attacks"


if a supply chain attack is susceptible to that, its purely the fault of the crowd the relies on those metrics




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: