Hacker News Reader

Comment by skeeter2020 | Hacker News Reader

skeeter2020

>> But the end effect was production never pulled from the internet

Having production ever pull from the interwebs just seems bonkers to me. Even if you (for some reason?) want to stay up-to-date on every single dependency release you should be pulling to your own repo with some sort of gated workflow. If you're doing continuous deployment you definitely want to put extra control around your external dependencies, and releasing your product quickly after they change is probably the rare exception.

View on HN

> Having production ever pull from the interwebs just seems bonkers to me.

Is it really that big of an issue if your package manager pins dependencies by hash?

I guess, public package registry can be down an brake your pipeline, that's a risk. But I don't see how it introduces any new security problems.

Pinning dependencies by hash is completely undermined by automation that then updates the pins without meaningful review, as is common.

I think that this is the issue then, not pulling dependencies from the internet directly.

> meaningful review No that I think about it, maybe for the first time in history it's actually feasible to review all the code in the repos using LLMs. Before LLMs were a thing, for any big project that would be way too much work to realistically do it.

Also, someone can provide code review of publicly available dependencies as a service, to avoid wasting tokens of reviewing same code again and again by each dev locally on their machine.

U wonder if anyone is already working on such service...

Most (all?) of the solutions offered are not providing a "code review service" but rather a "curated registry" one: download from us and we guarantee some things.

It's definitely more widely known/used for container images than individual software packages.

You can still lock versions, or even hashes. But it still leaves you open to "denial of service" if the "interwebs" acts up or someone unpublishes a package.

Reply on news.ycombinator.com