v0.10.3 source tarball checksum has been changed

[daeho-ro]

Hello, this is a homebrew maintainer and I have noticed that the checksum of v0.10.3 source tarball has been changed.

-4fb1d8122ec9e052ca91f127feb374b9feb01b50e202590f7fe3f38b37070aff
+e952fae10cc314395cd9ed531a96105d096db3458bc5dc71cfcae9ecdc58405a

It seems that the tag commit is moved.
Can you check this change is intended and so fine to use the new tarball?

Thanks,

[rob-p]

Thanks for the careful check, and thanks to the Homebrew maintainers for flagging it.

Short answer: the tag did move, the contents did not, and e952fae10cc314395cd9ed531a96105d096db3458bc5dc71cfcae9ecdc58405a is safe to use.

What the two tarballs contain

Both v0.10.3 tag commits point at the same git tree, so the file contents are bit-for-bit identical:

	old tag commit	new tag commit
commit	2a640e25afca61a14586a4e1f5e1b32055dc3aa3 (2026-07-16 12:35:23Z)	a2e296fb15436b56d2353bf421ad42a8d6255e01 (2026-07-20 03:43:41Z)
tree	b84e65245fcfe0a7fdd7d995d2231d80cf0fea61	b84e65245fcfe0a7fdd7d995d2231d80cf0fea61
parent	3dec9058f2c9745bc31e032c72f836722811af71	3dec9058f2c9745bc31e032c72f836722811af71

Identical tree SHA, only the commit timestamp differs. GitHub stamps the mtimes of the archive members from the commit date.

You can verify this yourself:

git clone https://github.com/COMBINE-lab/oarfish && cd oarfish
git rev-parse v0.10.3^{tree}                 # b84e65245fcfe0a7fdd7d995d2231d80cf0fea61
git cat-file -p 2a640e25 | grep ^tree        # same tree
curl -sL -o v0.10.3.tar.gz https://github.com/COMBINE-lab/oarfish/archive/refs/tags/v0.10.3.tar.gz
tar xzf v0.10.3.tar.gz
git archive v0.10.3 --prefix=ref/ | tar x && diff -r oarfish-0.10.3 ref   # no differences

The issue is that our release CI creates a "sanitized Cargo.toml" commit and tags it, and it triggers on any push to main whose head commit message carries our release marker. On 2026-07-20 some development work was pushed to main by mistake and main was reset back to the release commit 3dec905. That force-push replayed a push event whose head commit was still the v0.10.3 release commit, so the job ran a second time on the same source and — because it tagged with git tag --force / git push --force — repointed the tag at a freshly created (but content-identical) commit.

Unintentional, and entirely a CI issue on our side rather than a change to the release. #74 fixes it.

For the formula

• e952fae10cc314395cd9ed531a96105d096db3458bc5dc71cfcae9ecdc58405a is the current and final checksum for the v0.10.3 tag archive; no further moves have happened or will (main is unchanged since, and ci(sanitize): refuse to move an existing release tag #74 makes it impossible).
• I'd rather not move the tag back, since that would change the checksum a third time.
• If you want something that a tag move can't perturb, the release also ships a source.tar.gz asset, sha256 = de886868c4efb9ef7a77d0865bb4bda7effcf7143841c2a74e3ec714e49e4546 — release assets are immutable once uploaded.

[stefanb]

Thanks for thorough analysis, explanation and a proposed fix.

You could also consider enabling immutable releases on GitHub:
https://docs.github.com/en/code-security/concepts/supply-chain-security/immutable-releases