5 ms·

The same way it always has been done - vendor your deps.

by blueflow 11mo ago

hu3 11mo ago
that's what I do whenever feasible. Which is often
sph 11mo ago
To be fair this does only work in ecosystems where libraries are stable and don't break every 3 months as it often happens on the JS world. You can vendor your left-pad, but good luck doing that with a third-party SDK.
- CGamesPlay 11mo ago
  ... you vendor the third-party SDK? Nobody worth working with is breaking their SaaS APIs with that cadence.
joshstrange 11mo ago
That literally makes no difference at all. You’ll just vendor the malicious versions. No, a lock file with only exact versions is the safe path here. We haven’t seen a compromise to existing versions that I know of, only patch/minor updates with new malicious code. I maintain that the flexibility in npm package versions is the main issue here.
- blueflow 11mo ago
  You are using the word "vendoring" differently than i do, i mean some kind of private fork of the repository.
  - joshstrange 11mo ago
    You are using the word differently than everyone else I think. I’ve never heard someone using that word to mean maintain private forks. Then again, even private forks don’t protect you much more than package lock files and they are way more overhead IMHO. You still need some out-of-band process to pull upstream updates and aside from a built-in “cool down” (until you merge changes) I see that method as having a huge amount of downside. Yes, you sidestep malicious versions pushed to npm but now you own the build process for all your dependencies and you have to find time to update (and fix builds if they break) all your dependencies. Locking to a specific version and waiting some period of time (cool down) before updating is way easier and jus as safe IMHO.
    - Yokohiii 11mo ago
      Vendoring literally just means grabbing the source code from origin and commit it to your repo after a review. The expectation that every repo has important regular updates for you is pure FOMO. And if I don't do random updates for fun, nothing will every break. [redacted bullshit!]
      - joshstrange 11mo ago
        > Version locking wont help you all the time, i.e. if you build fresh envs from scratch. I'm confused on this. I would imagine it would protect/help you as long as releases are immutable which they are for most package managers (like npm). > Vendoring literally just means grabbing the source code from origin and commit it to your repo after a review. Hmm, I don't think it always necessarily means grabbing the source, it can also mean grabbing the built artifacts in my experience. My biggest issue with vendoring dependencies is it allows for editing of said dependencies. Almost everywhere I've worked that vendored dependencies (copied source or built versions in and committed them) felt the siren song of modifying said dependencies which is hell to deal with later.
        Yokohiii 11mo ago
        You are right about version locking, bullshit on my side, not sure what I was thinking. I personally don't have a problem with the general ability to change vendor code. The question is whether you want it in an specific case or not. If you update frequently then certainly not. But that decision should be deliberate team policy.
        joshstrange 11mo ago
        > I personally don't have a problem with the general ability to change vendor code. The question is whether you want it in an specific case or not. If you update frequently then certainly not. But that decision should be deliberate team policy. Fair, in the instances I ran into it was code that was downloaded and unzipped into a "js-library-name" folder but then the code was edited, even worse, the `.min.js` version wasn't touched, just the original one which led to some fun when someone "helpfully" switched to the min versions that didn't have the edit. IMHO, if you want to edit a library then you should be forking and/or making it super obvious that this is not "stock" library X. We also ran into issues with "just updated library Y" and only later realizing someone had modified the older version. But yes, if it's deliberate and obvious then I don't have an issue modifying, just as long as the team understands it's "their" code now and there is no clean upgrade path in the future.

The same way it always has been done - vendor your deps.

hu3 11mo ago

that's what I do whenever feasible. Which is often

sph 11mo ago

To be fair this does only work in ecosystems where libraries are stable and don't break every 3 months as it often happens on the JS world. You can vendor your left-pad, but good luck doing that with a third-party SDK.

CGamesPlay 11mo ago
... you vendor the third-party SDK? Nobody worth working with is breaking their SaaS APIs with that cadence.

joshstrange 11mo ago

That literally makes no difference at all. You’ll just vendor the malicious versions. No, a lock file with only exact versions is the safe path here. We haven’t seen a compromise to existing versions that I know of, only patch/minor updates with new malicious code. I maintain that the flexibility in npm package versions is the main issue here.

blueflow 11mo ago
You are using the word "vendoring" differently than i do, i mean some kind of private fork of the repository.
- joshstrange 11mo ago
  You are using the word differently than everyone else I think. I’ve never heard someone using that word to mean maintain private forks. Then again, even private forks don’t protect you much more than package lock files and they are way more overhead IMHO. You still need some out-of-band process to pull upstream updates and aside from a built-in “cool down” (until you merge changes) I see that method as having a huge amount of downside. Yes, you sidestep malicious versions pushed to npm but now you own the build process for all your dependencies and you have to find time to update (and fix builds if they break) all your dependencies. Locking to a specific version and waiting some period of time (cool down) before updating is way easier and jus as safe IMHO.
  - Yokohiii 11mo ago
    Vendoring literally just means grabbing the source code from origin and commit it to your repo after a review. The expectation that every repo has important regular updates for you is pure FOMO. And if I don't do random updates for fun, nothing will every break. [redacted bullshit!]
    - joshstrange 11mo ago
      > Version locking wont help you all the time, i.e. if you build fresh envs from scratch. I'm confused on this. I would imagine it would protect/help you as long as releases are immutable which they are for most package managers (like npm). > Vendoring literally just means grabbing the source code from origin and commit it to your repo after a review. Hmm, I don't think it always necessarily means grabbing the source, it can also mean grabbing the built artifacts in my experience. My biggest issue with vendoring dependencies is it allows for editing of said dependencies. Almost everywhere I've worked that vendored dependencies (copied source or built versions in and committed them) felt the siren song of modifying said dependencies which is hell to deal with later.
      - Yokohiii 11mo ago
        You are right about version locking, bullshit on my side, not sure what I was thinking. I personally don't have a problem with the general ability to change vendor code. The question is whether you want it in an specific case or not. If you update frequently then certainly not. But that decision should be deliberate team policy.
        joshstrange 11mo ago
        > I personally don't have a problem with the general ability to change vendor code. The question is whether you want it in an specific case or not. If you update frequently then certainly not. But that decision should be deliberate team policy. Fair, in the instances I ran into it was code that was downloaded and unzipped into a "js-library-name" folder but then the code was edited, even worse, the `.min.js` version wasn't touched, just the original one which led to some fun when someone "helpfully" switched to the min versions that didn't have the edit. IMHO, if you want to edit a library then you should be forking and/or making it super obvious that this is not "stock" library X. We also ran into issues with "just updated library Y" and only later realizing someone had modified the older version. But yes, if it's deliberate and obvious then I don't have an issue modifying, just as long as the team understands it's "their" code now and there is no clean upgrade path in the future.