Release v8.0.0 does not work with v8 or v8.0

[jimkring]

neither astral-sh/setup-uv@v8 nor astral-sh/setup-uv@v8.0 work -- only astral-sh/setup-uv@v8.0.0 works

[eifinger]

This is intentional. You can read about the reasoning in https://github.com/astral-sh/setup-uv/releases/tag/v8.0.0

[alexprengere]

Note that the release notes say to use setup-uv@8.0.0 which I think is a typo (tried it, did not work).

[eifinger]

Its missing the "v". Thank you for spotting it. I fixed it.

[jimkring]

This is intentional. You can read about the reasoning in https://github.com/astral-sh/setup-uv/releases/tag/v8.0.0

That makes perfect sense and I'm glad to see the attention to security. Plus, it's always seemed like a lot of extra work/setup on the side of actions publishers to continuously move the major and minor version tags on new fix releases.

[henryiii]

FYI, I believe this means that dependabot will no longer update v7 actions, since it only updates to a matching number of dots. So by trying to increase security, you are leaving many users stuck on a dead version with no security updates (unless you are keeping v7 and the last v7.x release updated with security patches for eternity?)

From a quick search, 26k repos are using v7 and 808 are using v8.0.0 (tag) and 2.7k (pinned). Pinned users (v7.x.x. and hash) got updated automatically, but I believe pretty much every other repo is and will remain stuck on v7.

I only know about this update because my "more important" repos are hash-pinned. Many of my repos use moving tags, because I prefer lower-churn for things like websites or very small tools; if I forget to accept the dependabot PR for a few months, I'd like to still get the latest security updates. It's particularly bad for tutorials, where I can't give students an easy version to type in anymore.

---

A friendly rant follows:

While I agree pins are mostly good, there are downsides, it's not just a "always better" model for everyone:

• Hashes can be spoofed to any fork. If I fork the repo, make a comment with a hash of 123a123a, then make a PR to some rep with astral-sh/setup-uv@123a123a # v8.0.1, it will look like I'm just innocently updating this to get some fix, but it's actually coming from some fork. Tools like zizmor can verify the tag commit matches the hash, which solves this security problem. I'd argue it's actually a much easier attack vector than taking over a repo and force-pushing tags, though. It just needs a PR that looks realistic that happens to bump an action too. Though it's per-repo, not a blanket attack.
• Pinning actions keeps you from getting fixes, too. After those attacks, the downstream repos could have pinned to a safe version, protecting downstream repos, but they can't ship that fix right away because users still have a bad pin! Similar issue with vulnerabilities that are announced after fixes quickly shipped. And people need to regularly update pins. Some repos just aren't important enough to manage all the time. Not every repo is a major library.
• Pinning doesn't actually solve anything unless you are running an audit on those pinned dependencies before you merge, which many projects won't do. All it does is changes the timing, which helps a little, but not a lot. The attach could just as easily been "new hacked versions released, dependabot updated, maintainer merged". If this becomes more common, in fact, catching these issues could become slower, because they affect fewer people right away. You can add a cooldown, which helps this point but hurts the last point.
• Old branches become out of date more quickly without patch releases.

Note

I am only listing some downsides of pinning above, not upsides. There are great upsides too, as already mentioned in the linked release notes.

I do think pinning is generally safer, and I personally should use it more (along with zizmor), but not everywhere. And now I'm going to have to try to find every repo I have (50+) with v7 and manually update it so dependabot starts updating this repo again. I might just start using @main on some of them.

Personally, I don't like trying to force everyone to follow a specific security model. I think it's nice to allow users to select the one that works best for them, and just encourage a better model, but follow the official actions. GitHub has a setting in every repo that lets you force pinned actions.

Note

All composite actions mush be hash-pinned, something I didn't realize till recently. Otherwise they can't be used in a repo that requires pinned actions.

Only tags associated with a release are immutable, if you don't make a "release" of v8, I think it's still updatable. (also, can't these be branches, not tags?) @main still works, by the way. ;) Also, publish-pypi-action has a unique branch name like releases/vX not just vX, to make it clear it is a branch not a tag.

Plus, it's always seemed like a lot of extra work/setup on the side of actions publishers to continuously move the major and minor version tags on new fix releases.

GitHub Actions has a tool for this that they use, and other actions can use it to (though we had to modify it for cibuildwheel to only produce vX.Y IIRC, as pining to vX there would not make sense).

---

To be clear, I'm likely to move quite a few repos over to zizmor + hash pinning, partially have already been planning to, and partially due to this change as it's one of the most important actions for me, so it is having the desired effect, I'm mostly annoyed that if I didn't have some hash-pinned repos already, I might never have known there was a v8 series of this action at all, dependabot would never update it.