1. 23
  1. 8

    Yep, lockfiles are essential. Not just for security – they also give you repeatable builds and make it less likely to get stuck in dependency hell and unable to back out again.

    1. 6

      This only works if your policy is to actually check lockfile updates, and to not treat their updates as a passing matter. You need to check what has been updated in a lockfile, and reasons for it. It’s no use having a lockfile if any dev can without much resistance just update it any time. But that then means that you have to put in work into managing it(and you should!) but few put in the effort of doing this “additional” work.

      1. 8

        From the article:

        Lockfiles don’t have any benefit if you aren’t reading the original source code or trusting the developer

        Dependency locking is orthogonal to dependency verification, and in fact they are complementary. Check out the OWASP guidelines (for NPM, they apply to most package managers as well).

        1. 6

          You get some benefit without actually doing that; when a supply chain attack is detected, the lockfile’s history in version control tell you when it was let in.

          1. 2

            This only works if your policy is to actually check lockfile updates, and to not treat their updates as a passing matter.

            I realise the topic of this article is supply-chain security, and in this context you’re right. But in the broader context of committing lockfiles, even treating it as a passing matter is useful if that’s all your team can muster. This actually ensures that everybody on your development team is running the same code, including dependencies, which is important more often than I would like.

            1. 2

              I find the opposite. Having no lockfiles for dev means that when we accidentally depend on features of versions narrower than our constraints specify, it often breaks for someone. This allows us to more quickly discover these problems and decide on a solution (either edit our code or change the constraints).

              1. 1

                But wouldn’t it just be better to avoid that breaking in the first place? Or at least relegate breaks to when a person is intentionally attempting an upgrade, at least.

                1. 1

                  If the code is broken with some version of the library, I’d rather know than not know. Better that one of us spends a few hours on it today than it just stay broken, or worse yet have it discovered by a user!

          2. 4

            It’s the early bind vs late binding, static linking vs dynamic linking debate. You want early binding / static linking in production so nothing breaks. You want late binding / dynamic linking in dev so you can test the newest system and keep from getting stuck on stale software.

            1. 2

              You can have both though (Or close to) if your deployment model allows it. Set up the lockfile and force production to use it, but automate a version bump on everything every night. As long as tests passed, require 1 person to merge the pr. Dependabot helps here a lot.

              This way you get both fresh versions and full lock in prod and dev.

            2. 3

              Rust is a strangely glaring omission from their table. (Yes, it has lockfiles.)

              1. 1

                Every port in FreeBSD Ports Collection has a distinfo file, which is essentially a lockfile. And you can use it for anything you use for building packages later on, it is language agnostic (in fact you can use it for all the other things like images and fonts as well).

                1. 2

                  In addition, the ports system has infrastructure for generating the distinfo files from a variety of different languages. For the official ports tree, all of the distfiles will mirror everything in the distinfo files and so you have a source of them even if upstream goes away.