💾 Archived View for erock.io › 2022 › 06 › 02 › on-language-package-managers captured on 2023-01-29 at 15:50:58. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-07-16)
-=-=-=-=-=-=-
Stardate 2022-06-02
The more I read about supply chain attacks and security issues revolving around language package managers, the more pressing I think this issue has become.
They join a growing club of broken-by-design package managers which publish packages uploaded by vendors directly, with no review step, and ship those packages directly to users with no further scrutiny.
https://drewdevault.com/2022/05/12/Supply-chain-when-will-we-learn.html
On one hand, I totally agree with Drew here. The fact that there are virtually no security measures in place for publishing packages to a registry is a source of our problems here.
However, I'm also of the opinion that regardless of what protections a package manager puts into place for consumers, the ultimate responsibility falls on the consumer to properly vet their dependencies. I'm all for having standard practices put into effect to make it easier to follow a secure path, but that's about where I draw the line.
I think having a third-party review the package before it can be listed in the registry is fine. However, there still needs to be an easy way to side-load those packages then. There have been many times where I wanted to publish a package just to proply test it works properly end-to-end.
I know Drew uses golang quite a bit, I wonder what he thinks about the no-registry paradigm that golang employs. I think it's even easier to use than npm, but that comes with a big downside: there is no friction between creating a git repo with a golang package and a consumer using it. No review step and no further scrutiny.
I've been trying to learn more about products or services that help prevent supply chain attacks and compiled a meager list here:
gemini://lists.sh/erock/bookmark-supply-chain-security
I really wonder if services like these will ever get traction. The reason why there's a blossoming ecosystem revolving around popular package managers is because they lower the barrier to entry to consume code. Adding this security step sounds great but in reality, I really wonder how many people will use it. I guess one could argue that TLS is equally a pain and we have been seeing pretty awesome tooling around that to make it as simple as possible.
As an aside, I started using caddy instead of nginx primarily because of its auto-tls functionality.
If anyone else has any thoughts on how to help prevent supply chain attacks, I'd love to read about them. I'm too early in my research to provide any concrete thoughts of my own. I do think regardless of what is proposed, it needs to strike a balance between easy package publishing and providing the tools for a package developer to be successful without jumping through a dozen hoops.
--
Want to chat? email me at gemlog@erock.io