3 ms·

>> 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 s

by skeeter2020 8mo ago

>> 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.

vova_hn2 8mo ago
> 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.
- rlpb 8mo ago
  Pinning dependencies by hash is completely undermined by automation that then updates the pins without meaningful review, as is common.
  - vova_hn2 8mo ago
    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...
    - zvr 8mo ago
      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.
actionfromafar 8mo ago
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.

vova_hn2 8mo ago

> 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.

rlpb 8mo ago
Pinning dependencies by hash is completely undermined by automation that then updates the pins without meaningful review, as is common.
- vova_hn2 8mo ago
  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...
  - zvr 8mo ago
    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.

actionfromafar 8mo ago

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.