Comment by woodruffw

3 days ago

> it might not be so explicitly state, but a desire to have constant updated-ness w/ security patches amounts to an argument against pinning

When you want to update, you update the hashes too. This isn’t an issue in any other packaging ecosystem, where locking (including hashing) is a baseline expectation. The main issue is developer ergonomics, which comes back to GitHub Actions providing very poor package management primitives out of the box.

(This is the key distinction between updating and passively being updated because you have mutable pointers to package state. The latter gets confused for the former, but you almost always want the former.)

6 comments

woodruffw

Reply
deathanatos  2 days ago

This isn't a bad distinction that you've made, I just think even lockfiles (what you're suggesting, essentially) still fall prey to the same paradox I'm suggesting.

Yes, lockfiles prevent "inadvertent" upgrades, in the sense that you get the "pinned" version in the lockfile. So if we go with the lockfile, we're now on the "pinned" side of the paradoxical coin. Yes, we no longer get auto-pwned by supply chain, but security's problem is "why are we not keeping up to date with patches?" now, since the lockfile effectively prevents them.

And then you see tooling get developed, like what Github has in the form of Dependabot, which will automatically update that lockfile. Now we're just back to the other side of the paradoxical coin, just with more steps.

(This isn't to say we shouldn't do lockfiles. Lockfiles bring a lot of other benefits, and I am generally in favor of them. But I don't think they solve this problem.)

  • woodruffw  2 days ago

    I don’t think this is a paradox, it’s just a process. You use lockfiles to establish consistent resolutions, and then you use dependency management tooling to update those lockfiles according to various constraints/policies like compatibility, release age, known vulnerabilities, etc.

    (Another framing is that you might want floating constraints for compatibility reasons, but when actually running software you basically never want dependencies changing implicitly beneath you, even if they fix things. Fixes should always be legible, whether they’re security relevant or not.)