5 ms·

I somewhat agree. But it's not that simple in practice. For example, I pin every single version and the container fails a security scan because it's not using l

I somewhat agree. But it's not that simple in practice. For example, I pin every single version and the container fails a security scan because it's not using latest versions of everything. Or I pin to arbitrary versions that happened to be latest when pip/npm/terraform first created the precious word-of-god lock file, leaving future engineers afraid to upgrade those packages because "Chesterton's Fence". Pinning versions creates work in the future. Using latest versions can result in ad-hoc breakages and security risk. So instead of saying "v1.22=good, latest=bad" and talking generally about the fact that lock files exist in most decent systems, I'd like an article that contains example strategies for paying back the tech debt of a thousand arbitrarily pinned versions across your code projects. I like the idea of deleting the lock file on a regular cadence, accepting whatever new shit comes in, perhaps bumping a major version number, and then testing the crap out of everything and leaving this new artifact in integration/staging for a few extra days. If things go wrong between builds, then you have the lock files in git (and in your artifacts) to let you know what changed. If it turns out that you now have a real reason to pin a specific package (ie: it broke something), then you have to find some way to note that outside of the usual lock files, since they arbitrarily lock everything.

mr_tristan 5y ago
Pinning can be far less painful with tooling to review and manage all the changes. One example would be the Maven versions plugin: you can use it to query "what's been updated", update to next release, etc. The list of goals is pretty explanatory, and a good starting point: https://www.mojohaus.org/versions-maven-plugin/ https://www.mojohaus.org/versions-maven-plugin/ When evaluating new toolchains, I often ask myself "what is the versions plugin equivalent here". There's often commercial offerings that help this process out. Dependency management is one of these topics that rarely gets attention until much later in the ecosystem's lifetime. So chances are you'll need to find or create tooling to fill gaps. I mean, you can do the whole "damn the torpedos and see what breaks" approach, but, I'd prefer a way to review changes. And I'd prefer doing those updates _separate_ from other changes.
88913527 5y ago
Needlessly upgrading all of your packages leaves you open to supply chain attacks. If one of those NPM packages got quietly compromised (and my lockfile likely has 4-to-5 digits worth of dependencies in it), you invested time in making what amounts to an unneeded change to expose yourself.
- duped 5y ago
  The only real defense to supply chain attacks are audits and self hosted dependencies/packages.
  - roblabla 5y ago
    > self hosted dependencies/packages. Why? If your lockfile specifies and enforces the hash of the package, you don't need to self-host it - the lockfile will take care of detecting supply chain compromises that swaps a package with another. 100% agree on audits being necessary.
    - delusional 5y ago
      You're still downloading random stuff from the internet. A vulnerability in your package manager could let an attacker bypass the hash check, or they could discover a hash collision. If you really want to be sure, having the exact bits on a system you control seems like the right move.
    - charcircuit 5y ago
      Self hosting protects against attacks against the availability of your supply chain.
- raffraffraff 5y ago
  Ok, so let's say it's day one: how do you choose all of your initial pinned versions? How do you know they're safe? What if you luck-out in the supply chain attack lottery and pin malware?
  - 5y ago
armchairhacker 5y ago
Pinning versions creates future work but so does using the latest version. Vulnerability discovered in old version vs. vulnerability maliciously inserted in new version; software engineers afraid of upgrading because of breaks vs these breaks actually occurring because of an unexpected upgrade. I personally prefer pinned versions because whenever I try to install some old github example or other code, I usually end up getting stuck with errors unless everything (compiler, dependencies, etc.) are pinned. Gradle projects almost always work no matter how old (Gradle pins the dependencies, JVM, and even the version of Gradle), whereas npm and CMake projects (which are built with new compilers and usually new dependencies) often fail.
lamontcg 5y ago
You need to have a CD system which takes equality pinned deps and bumps them when new versions come through and automatically runs the new versions through whatever your test/integration/production environments looks like. And you should have sufficient integration testing that you should have confidence that an automated process should be able to decide if the new version should get deployed to prod (being realistic you probably want to confine these deployments to some sort of reasonable business hours). Then the tech debt gets addressed automatically without any work. The work is all up front to write the tests that give you confidence about deployment to production, but that is work that needs to happens and pays off. You shouldn't need to have human testing in the loop.
- crummy 5y ago
  Do people have automated tests to validate their SMSs are sent correctly (and received by a real phone)? Or that credit card payments are made correctly? These are things I use third party libraries for, and what I worry might break when I upgrade dependency versions.
  - sbierwagen 5y ago
    Most payments vendors will have test CC numbers for integration testing. One of Paypal's test numbers is 5555555555554444, for example. https://developer.paypal.com/api/nvp-soap/payflow/integration-guide/test-transactions/ https://developer.paypal.com/api/nvp-soap/payflow/integratio...
  - adenner 5y ago
    Depends, how big of a deal is it when they break?
  - delusional 5y ago
    I guess the question becomes how far out you want to test. If your credit card processor is a third party they could technically break something, regardless of which version of their library you use. In that case, do you really care that a transaction goes through, or do you just care that you used your third parties interface correctly (be that rest or binary api calls). If your requirements aren't that sharp, like maybe you can take a day or two to process the credit card payments, you could get away with monitoring your application and configuring alarms for if no transactions go through. That way you'd catch errors originating from your third party as well.
nextaccountic 5y ago
> For example, I pin every single version and the container fails a security scan because it's not using latest versions of everything. This security scan would be absurd. The amount of churn of updating everything the day it is released would be insane, specially wrt. breaking changes.
karmelapple 5y ago
Dependabot is great for this. We have everything pinned, but dependabot takes care of a bunch of manual steps to upgrade a dependency: it updates package.json, package-lock.json, pulls release notes for all the changes since your pinned version, and makes a PR and triggers your CI build. We’ve found many broken builds thanks to this, and could then create an issue in our tracker to tackle that tech debt later. If the build doesn’t break, we review the new version’s release notes, and sometimes even look at the code changes of the open source package. Overall it’s helped us keep more up to date, has made upgrading versions of Node less painful, and even helped us adopt some improvements sooner than we otherwise would have.

mr_tristan 5y ago

Pinning can be far less painful with tooling to review and manage all the changes. One example would be the Maven versions plugin: you can use it to query "what's been updated", update to next release, etc. The list of goals is pretty explanatory, and a good starting point: https://www.mojohaus.org/versions-maven-plugin/ https://www.mojohaus.org/versions-maven-plugin/ When evaluating new toolchains, I often ask myself "what is the versions plugin equivalent here". There's often commercial offerings that help this process out. Dependency management is one of these topics that rarely gets attention until much later in the ecosystem's lifetime. So chances are you'll need to find or create tooling to fill gaps. I mean, you can do the whole "damn the torpedos and see what breaks" approach, but, I'd prefer a way to review changes. And I'd prefer doing those updates _separate_ from other changes.

88913527 5y ago

Needlessly upgrading all of your packages leaves you open to supply chain attacks. If one of those NPM packages got quietly compromised (and my lockfile likely has 4-to-5 digits worth of dependencies in it), you invested time in making what amounts to an unneeded change to expose yourself.

duped 5y ago
The only real defense to supply chain attacks are audits and self hosted dependencies/packages.
- roblabla 5y ago
  > self hosted dependencies/packages. Why? If your lockfile specifies and enforces the hash of the package, you don't need to self-host it - the lockfile will take care of detecting supply chain compromises that swaps a package with another. 100% agree on audits being necessary.
  - delusional 5y ago
    You're still downloading random stuff from the internet. A vulnerability in your package manager could let an attacker bypass the hash check, or they could discover a hash collision. If you really want to be sure, having the exact bits on a system you control seems like the right move.
  - charcircuit 5y ago
    Self hosting protects against attacks against the availability of your supply chain.
raffraffraff 5y ago
Ok, so let's say it's day one: how do you choose all of your initial pinned versions? How do you know they're safe? What if you luck-out in the supply chain attack lottery and pin malware?
- 5y ago

armchairhacker 5y ago

Pinning versions creates future work but so does using the latest version. Vulnerability discovered in old version vs. vulnerability maliciously inserted in new version; software engineers afraid of upgrading because of breaks vs these breaks actually occurring because of an unexpected upgrade. I personally prefer pinned versions because whenever I try to install some old github example or other code, I usually end up getting stuck with errors unless everything (compiler, dependencies, etc.) are pinned. Gradle projects almost always work no matter how old (Gradle pins the dependencies, JVM, and even the version of Gradle), whereas npm and CMake projects (which are built with new compilers and usually new dependencies) often fail.

lamontcg 5y ago

You need to have a CD system which takes equality pinned deps and bumps them when new versions come through and automatically runs the new versions through whatever your test/integration/production environments looks like. And you should have sufficient integration testing that you should have confidence that an automated process should be able to decide if the new version should get deployed to prod (being realistic you probably want to confine these deployments to some sort of reasonable business hours). Then the tech debt gets addressed automatically without any work. The work is all up front to write the tests that give you confidence about deployment to production, but that is work that needs to happens and pays off. You shouldn't need to have human testing in the loop.

crummy 5y ago
Do people have automated tests to validate their SMSs are sent correctly (and received by a real phone)? Or that credit card payments are made correctly? These are things I use third party libraries for, and what I worry might break when I upgrade dependency versions.
- sbierwagen 5y ago
  Most payments vendors will have test CC numbers for integration testing. One of Paypal's test numbers is 5555555555554444, for example. https://developer.paypal.com/api/nvp-soap/payflow/integration-guide/test-transactions/ https://developer.paypal.com/api/nvp-soap/payflow/integratio...
- adenner 5y ago
  Depends, how big of a deal is it when they break?
- delusional 5y ago
  I guess the question becomes how far out you want to test. If your credit card processor is a third party they could technically break something, regardless of which version of their library you use. In that case, do you really care that a transaction goes through, or do you just care that you used your third parties interface correctly (be that rest or binary api calls). If your requirements aren't that sharp, like maybe you can take a day or two to process the credit card payments, you could get away with monitoring your application and configuring alarms for if no transactions go through. That way you'd catch errors originating from your third party as well.

nextaccountic 5y ago

> For example, I pin every single version and the container fails a security scan because it's not using latest versions of everything. This security scan would be absurd. The amount of churn of updating everything the day it is released would be insane, specially wrt. breaking changes.

karmelapple 5y ago

Dependabot is great for this. We have everything pinned, but dependabot takes care of a bunch of manual steps to upgrade a dependency: it updates package.json, package-lock.json, pulls release notes for all the changes since your pinned version, and makes a PR and triggers your CI build. We’ve found many broken builds thanks to this, and could then create an issue in our tracker to tackle that tech debt later. If the build doesn’t break, we review the new version’s release notes, and sometimes even look at the code changes of the open source package. Overall it’s helped us keep more up to date, has made upgrading versions of Node less painful, and even helped us adopt some improvements sooner than we otherwise would have.