juicefs: update checksum

[stefanb]

• Have you followed the guidelines for contributing?
• Have you ensured that your commits follow the commit style guide?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

---

Found in

• go 1.25.0, go@1.24 1.24.6 (new formula) #226636

Upstream issue:

• Checksum confirmation juicedata/juicefs#6287

[yuhr123]

Hello, I am JuiceFS team responsible for maintaining third-party software repositories, may I ask why you want to modify the checksum of this package? If you need any collaboration, feel free to contact me.

[stefanb]

@yuhr123, thanks for asking.

In

• go 1.25.0, go@1.24 1.24.6 (new formula) #226636
  We detected hash mismatch and logged:

  juicefs: hash mismatch: Expected: df779a718a608d47fdf1f3cd44c314d1cbc8fac43c4f862d2d40e768fecf0bb0 Actual: c2d098797bb9bc0bcb75ac1461cd1c06a8306dd3375a6d221f17c2eed091fee6

The hash apparently changed since

• juicefs 1.3.0 #229202

Now we're trying to fix the inconsistency, but would like to know the reason for hash change. Was the tag moved (bad git practice) or was the repository compromised or something else happened?

In

• Checksum confirmation juicedata/juicefs#6287

@daeho-ro suggests the git tag was possibly moved due to multiple workflow runs for some reason (eg workflow failure). In such cases it would be better to tag a patch release (eg 1.3.1, 1.3.2...) and run the workflow on those instead of moving the release tag.

Can you please investigate and confirm what happened?

[yuhr123]

Can I understand it this way: a version change in a maintained go formula has affected a series of projects that depend on go (juicefs is one of them). Due to different go versions, compiling the same source code will produce different checksum values. Therefore, the current problem has occurred?

[bevanjkay]

The issue is that checksum for the release tarball https://github.com/juicedata/juicefs/archive/refs/tags/v1.3.0.tar.gz has changed since it was released. This suggests that something changed with the tag, so we need to work out the reason to make sure the release hasn't been compromised.

[yuhr123]

Hi @bevanjkay, thank you for clarifying the cause further, I have also informed our engineering team and we will work with you to investigate possible causes.

[zhijian-pro]

Hello, I'm an engineer from juicefs. We haven't moved the tag v1.3.0.
I have a question about how this checksum value is calculated. Does your program first obtain the tag, then download the code archive, and finally calculate the sha256 to get this result?

[bevanjkay]

Yes the checksum is calculated by downloading the release tarball (https://github.com/juicedata/juicefs/archive/refs/tags/v1.3.0.tar.gz).

For context, in order for the existing checksum (currently incorrect value) to be merged, the checksum was first calculated during the 'version bump', and then reproduced across 8 CI runs on different architecture.

[jiefenghuang]

Hello, I am the engineer from JuiceFS. The 1.3.0 version was packaged three weeks ago, specifically in this CI run: https://github.com/juicedata/juicefs/actions/runs/16106096397. The tag has not been modified. The only change made was marking release 1.3.0 "Set as the latest release" after v1.2.4 was published.

[daeho-ro]

We are using source tarball and it was create a month ago. And

And this is why I am suspecting the branch release-1.3.

[jiefenghuang]

Yes, the last commit is 30190ca, made on July 3. After completing verification, the release was published on July 7.

[daeho-ro]

I don't understand what is happened here, maybe release ci can replace source tarball or not. 🤔

Anyway, I think this is enough to confirm that the current tarball is fine.

Thank you, @yuhr123 , @jiefenghuang .

[github-actions]

🤖 An automated task has requested bottles to be published to this PR.

Caution

Please do not push to this PR branch before the bottle commits have been pushed, as this results in a state that is difficult to recover from. If you need to resolve a merge conflict, please use a merge commit. Do not force-push to this PR branch.