3 ms·

I think a benefit of a smaller number of larger packages is reduces the number of parties you need to trust. The people in charge of each larger package can re

I think a benefit of a smaller number of larger packages is reduces the number of parties you need to trust. The people in charge of each larger package can review contributions made to it and have the authority to reject code that includes attacks. If a larger package doesn't do a good job of preventing attacks, its reputation will decline and because there are fewer packages involved it is easy to remember these reputations.

ljm 3y ago
It's never as simple as finding exploits in code review though. Trusted accounts are compromised or the credentials to the package manager are compromised or there is some other supply chain attack. Larger packages tend to have a lot more community and governance around them than your typical JS-style function-as-a-dependency left-pad affair, so maybe they're safer if computer accounts are gatekeeping the published artifacts rather than having individuals embed their personal keys or tokens into the publishing pipeline. I've had this debate before and, as far as dependencies go, sometimes you have to rip the bandaid off and audit your shit, and understand why exactly you outsourced something to a package.
thephyber 3y ago
That seems intuitive. I agree in the sense that smaller supply chain surface area is easier to secure/verify. But it also makes the developers/maintainers of the few packages much brighter targets. I’m more of a fan of standardizing how libraries can be rated, evaluated, trusted, marketed, etc. we need more efforts analogous to Consumer Reports / Underwriters Laboratories. So far there are a few for-profit companies in this space, including Google.