Commit of Release v2.0.0 does not belong to any branch on this repository

[abuechler]

The message for commit 485a9d42d3a73031f12ec201c457e2162c45d02d and release v2.0.0 is worrying:

This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

[abuechler]

Same is true for v2.1.0 🤔

[zimeg]

Hey @abuechler 👋 Thanks so much for sharing this finding! 🔍

The notice shown can be concerning for sure, but this is an artifact of our current release process at the moment. We package a distribution into a single commit for each tag to avoid cluttering the main branch.

Since these changes are pushed separate from main the warning appears, but we might consider making a persisting branch called latest for these changes?

This will keep these changes on a known branch while allowing folks to also use the most recent packagings 🎁

[zimeg]

📝 Some exploration is showing that the "parent" commit of the tagged release b0fa283 matches main of the release commit as expected.

A limitation does exist with the proposed latest branch persisting above though, since branches must have linear histories and we can't change the tagged commit SHA. For reference releases follow something like:

*---*---*---*---*---*---* (main)
 \       \           \
  *       *           *
  v2.0.0  v2.1.0-rc1  v2.1.0
  v2.0                v2.1
                      v2

🔍 I am still thinking that the latest branch should point to the latest release, but I do not think we can keep track of past releases with this setup.

While this isn't ideal for the reasons this issue calls out, it matches our recommendation to remain with the most recent release:

We recommend using the latest version of this Action for the most recent updates and fixes.

Some discussion in #441 also suggests showing the SHA in documented examples, and with some help from the so kind and wonderful @dependabot this might be an alright path forward.

I'd love to know your thoughts and what others think before moving forward with this!

[abuechler]

Hello @zimeg 👋

Thank you for the explanation and your work on this action!

Git branches and tags are not expensive, I hope you'll find another way to release this action. 🙏 I'm currently pinning all actions to full commit SHA (and there are a lot of them) and this is the only one I found with this kind of "issue". In the light of the recent tj-actionssecurity disaster, I think it would help a lot to do this differently, even though you have your reasons to do releases that way.

[v1v]

In our case, we have a hard policy to avoid using any actions if their sha commits are shown with the banner 'This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.'

If it helps, GitHub added a banner to highlight that it might not be secure to use those commits, that's part of some work coming from some findings from Chainguard:

• https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd

They called that attack Imposter Commits.

[zimeg]

@abuechler @v1v A workflow to create release branches on new releases has merged and past @v2 releases now have corresponding branches to avoid these imposter commits 👻

The following pattern is being used to keep packaged distributions one commit off of main:

• release/v2.0.0: Release Notes 📚
• release/v2.1.0: Release Notes 📚

Thank you both for sharing the usefulness of branches and patterns that other projects have used to avoid these security concerns - it's appreciated so much!

Also please do feel free to write in with other ideas or questions of findings whenever too 💌

[v1v]

Thanks so much @zimeg 🙇