7 ms·

>7. This incident has reminded that many people mistakenly assume that git tags are immutable, especially if they are in semver format. Although it's rare for s

>7. This incident has reminded that many people mistakenly assume that git tags are immutable, especially if they are in semver format. Although it's rare for such tags to be changed, they are not immutable by design IME, this will be more "learned" than "reminded". Many many people set up pipelines to build artefacts based on tags (e.g. a common practise being "on tag with some pattern, then build artefact:$tag") and are just surprised if you call out the flaws. It's one of many practises adopted because everyone does it but without basic awareness of the tradeoffs. Semver is another similar case of inherited practise, where surprisingly many people seem to believe that labelling software with a particular string magically translates into hard guarantees about its behaviour.

nine_k 2y ago
Tags can be signed, and the signature can be verified. It's about as easy as signing / verifying commits. One can even make signing tags as the default option when creating tags. This won't help in this case though, because a legitimate bot was tricked into working with a rogue commit; a tricked bot could as well sign a tag with a legitimate key. "Immutable tags" of course exist, they are commit hashes, but they are uninformative :(
junon 2y ago
I theorized about this vulnerability a while back when I noticed new commits didn't disable automerging. This is an insane default from GH. EDIT: seems GitHub has finally noticed (or started to care); just went to test this and auto merge has been seemingly disabled sitewide. Even though the setting is enabled, no option to automerge PRs shows up. Seems I was right to worry! EDIT2: We just tested this on GitLab's CI since they also have an auto-merge function and it appears they've done things correctly. Auto-merge enablement is only valid for the commit for which it was enabled; new pushes disable auto-merge. Much more sensible and secure.
- WhyNotHugo 1y ago
  GitLab has had this behaviour (disable auto-merge when new commits are pushed) since long before GitHub even had auto-merge. It’s such an obvious attack vector, I’m pretty sure I tested GitLab soon after the feature initially rolled out.
klysm 2y ago
How else should we do it?
- sunnybeetroot 2y ago
  By commit hash
  - bboreham 2y ago
    It seems to me that pinning to a sha was not sufficient; the Renovate bot was updating actions referenced by sha. Example: https://github.com/chains-project/maven-lockfile/pull/1111/files https://github.com/chains-project/maven-lockfile/pull/1111/f... This appears to be governed by the `pinGitHubActionDigests` helper configured in `renovate.json`.

nine_k 2y ago

Tags can be signed, and the signature can be verified. It's about as easy as signing / verifying commits. One can even make signing tags as the default option when creating tags. This won't help in this case though, because a legitimate bot was tricked into working with a rogue commit; a tricked bot could as well sign a tag with a legitimate key. "Immutable tags" of course exist, they are commit hashes, but they are uninformative :(

junon 2y ago

I theorized about this vulnerability a while back when I noticed new commits didn't disable automerging. This is an insane default from GH. EDIT: seems GitHub has finally noticed (or started to care); just went to test this and auto merge has been seemingly disabled sitewide. Even though the setting is enabled, no option to automerge PRs shows up. Seems I was right to worry! EDIT2: We just tested this on GitLab's CI since they also have an auto-merge function and it appears they've done things correctly. Auto-merge enablement is only valid for the commit for which it was enabled; new pushes disable auto-merge. Much more sensible and secure.

WhyNotHugo 1y ago
GitLab has had this behaviour (disable auto-merge when new commits are pushed) since long before GitHub even had auto-merge. It’s such an obvious attack vector, I’m pretty sure I tested GitLab soon after the feature initially rolled out.

klysm 2y ago

How else should we do it?

sunnybeetroot 2y ago
By commit hash
- bboreham 2y ago
  It seems to me that pinning to a sha was not sufficient; the Renovate bot was updating actions referenced by sha. Example: https://github.com/chains-project/maven-lockfile/pull/1111/files https://github.com/chains-project/maven-lockfile/pull/1111/f... This appears to be governed by the `pinGitHubActionDigests` helper configured in `renovate.json`.