Pinning-by-hash upgrade

[laurentsimon]

Dependabot supports a versioning strategy.

Some developers may want to pin by hash. It's useful to further mitigate against compromised packages. Although this is already supported by dependabot, dependabot does not allow upgrading from version pinning to hash pinning. This makes it very time-consuming for developers to upgrade. For example, if a current dockerfile contains FROM [email protected] and maintainers want to upgrade all such occurrences to FROM [email protected]:hash, there's no easy way to tell dependabot to do that, AFAIK.

Having an option to do that would be amazing. It could possibly live under the versioning-strategy.

Is this something you'd be interested in adding, or accept PRs?

Thanks!

[thepwagner]

I'd dig it!

There's a potentially inspirational implementation in https://github.com/thepwagner/action-update-docker , specifically thepwagner/action-update-docker#59. There, configuration looks like: sha_pinning: true.

One idea for scope creep: in addition to maintaining the image as a pinned hash, I liked keeping the readable tag in a nearby comment: e.g. FROM alpine:3.11.0 would become FROM alpine@sha256:hash # alpine:3.12.0.

One question: what should this feature do if it encounters a mutable tag (e.g. debian:buster). Would you expect Dependabot to open a PR with the new hash every time that tag is updated?

[laurentsimon]

I'd dig it!

There's a potentially inspirational implementation in https://github.com/thepwagner/action-update-docker , specifically thepwagner/action-update-docker#59. There, configuration looks like: sha_pinning: true.

thanks for the link!

One idea for scope creep: in addition to maintaining the image as a pinned hash, I liked keeping the readable tag in a nearby comment: e.g. FROM alpine:3.11.0 would become FROM alpine@sha256:hash # alpine:3.12.0.

good idea. For docker specifically, we could use FROM alpine:3.11.0@sha256:hash but it'd be specific to docker. Comments seems more portable.

One question: what should this feature do if it encounters a mutable tag (e.g. debian:buster). Would you expect Dependabot to open a PR with the new hash every time that tag is updated?

Good question. Using a mutable tag means the image may change very often, so sending a PR on each change may be cumbersome for maintainers. On the other hand, this is high-risk. To keep things simple, I suppose we could ignore this case for now, as it seems to be the intention of the developer to not pin the image. That's insecure, but maybe this is something another tool could warn about, e.g. scorecard

wdut?

@inferno-chromium FYI

[ChrisCarini]

I, too, would like to see this feature. Has there been any further thought / progress here? I'd try to contribute something, but I do not know Ruby, and have spent a few hours already struggling to get this project opened in VSCode inside dev container. :(

[thepwagner]

I think https://docs.renovatebot.com/configuration-options/#pindigests works exactly like this.

[github-actions]

👋 This issue has been marked as stale because it has been open for 2 years with no activity. You can comment on the issue to hold stalebot off for a while, or do nothing. If you do nothing, this issue will be closed eventually by the stalebot. Please see CONTRIBUTING.md for more policy details.

[DilumAluthge]

I believe that this feature request is still relevant and this should remain open.