Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

renovate: automerge updates to Dockerfile #26

Merged
merged 1 commit into from
Dec 10, 2024
Merged

Conversation

nadiamoe
Copy link
Member

Together with release-on-main-push, this should make most of this repo maintenance free, other than updating actions.

@nadiamoe nadiamoe requested a review from a team as a code owner November 22, 2024 08:50
@mem mem force-pushed the renovate-automerge branch from 31270f8 to 6234f40 Compare November 26, 2024 23:06
@mem
Copy link
Contributor

mem commented Nov 26, 2024

Uhm...

The whole story behind pinning sha's is that if a bad actor breaks into whatever, they might be able to republish an artifact under the same version but with a different sha.

Renovate will update the sha if it changes (without the version changing), won't it?

So letting it automerge that kind of change is counter to the idea of pinned versions providing a safety net against that scenario, isn't it?

@nadiamoe
Copy link
Member Author

nadiamoe commented Nov 27, 2024

The whole story behind pinning sha's is that if a bad actor breaks into whatever, they might be able to republish an artifact under the same version but with a different sha.

That is one way to see it. The way I see it, which I think it's more pragmatic, is that I get updates from people who push over an existing tag. There are valid and less valid reasons to do it, but the sheer reality is that people do it anyway.

Renovate will update the sha if it changes (without the version changing), won't it?

Yes

So letting it automerge that kind of change is counter to the idea of pinned versions providing a safety net against that scenario, isn't it?

Yes, it's a tradeoff I'm taking. I think the security losses are minimal compared with the benefits we get from hands-off maintenance, but we can discuss that.

On the question of "why bother SHA pinning if we're automerging", I think it's better to have it pinned regardless. Not only for the reason outlined above (we get upgrades if someone willingly retags), but because that event is logged, tested, and revertable.

Together with release-on-main-push, this should make most of this repo
maintenance free, other than updating actions.
@nadiamoe nadiamoe enabled auto-merge (rebase) December 10, 2024 16:29
@nadiamoe nadiamoe disabled auto-merge December 10, 2024 17:19
@nadiamoe nadiamoe merged commit 2591540 into main Dec 10, 2024
3 checks passed
@nadiamoe nadiamoe deleted the renovate-automerge branch December 10, 2024 17:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants