Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sha256 mismatch for Helm chart eck-operator-2.7.0 #6714

Closed
thbkrkr opened this issue Apr 21, 2023 · 1 comment · Fixed by #6704
Closed

sha256 mismatch for Helm chart eck-operator-2.7.0 #6714

thbkrkr opened this issue Apr 21, 2023 · 1 comment · Fixed by #6704
Labels
>bug Something isn't working

Comments

@thbkrkr
Copy link
Contributor

thbkrkr commented Apr 21, 2023

Reported in the Elastic Stack Community Slack:

In https://helm.elastic.co/index.yaml, eck-operator 2.7.0 is listed as being at https://helm.elastic.co/helm/eck-operator/eck-operator-2.7.0.tgz and having sha256 digest:

7e7bac17ab8239af048e15201c2b1b2f93ef9bdc3560da5e91ad0e7b568f43af

But that doesn't match the tgz file being served at that url:

> curl -s https://helm.elastic.co/helm/eck-operator/eck-operator-2.7.0.tgz | sha256sum
e1810361abd0a73220d075508a714e1864692cb6a07d521a3c025386ef0ccb6d

I'm relatively new to helm, but for 2.6.1 the checkums matched (although not for 2.6.0). (This came up when copying into an air-gapped environment.)

@thbkrkr thbkrkr added the >bug Something isn't working label Apr 21, 2023
@thbkrkr
Copy link
Contributor Author

thbkrkr commented Apr 21, 2023

During 2.7.0 release, we were affected by a bug that causes an issue to update the Helm repo index.

TL;DR when releasing two different charts in a small time interval, the release of second chart overrides the recent index update made for the release of the first chart.

After identifying the issue, we ran again the release for Helm chart eck-operator-2.7.0. This created a new eck-operator-2.7.0.tgz with a different sha256, but it didn't upload it because the helm release tool currently doesn't allow to upload an existed file (code) and eventually updated the index with the new sha256.

Hence the question: why do have different sha256 when creating eck-operator-2.7.0.tgz from the same source files?

I think this is actually due to gzip and is intentional by design. Part of the gzip header has a mod time for whatever is compressed in the file, so by calling helm package multiple times, each one creates their own tarball which is then packaged by gzip and given a unique shasum because the modtime differed.
source: helm/helm#3612 (comment)

From that, we have two problems:

  • when we publish an Helm chart in x.y.z-snapshot, we never override the .tgz, only the index
  • if we re-publish an Helm chart in x.y.z (event that should not happen), we don't override the .tgz, only the index

Proposed changes for the Helm release tool:

  • allow to override the .tgz for snapshots releases (dev Helm repo)
  • not allow to override the .tgz for tagged releases but also not allow to update the index (prod Helm repo)

During the 2.7.0 release, we should have removed eck-operator-2.7.0.tgz before running the tool again to update the index correctly to avoid this sha256 mismatch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant