`helm package` should produce bitwise-deterministic tar files #3612

cmaher · 2018-03-05T23:12:10Z

We have a CI process for publishing charts where we try to determine if pushed repository needs to have it's charts built and published. We would like to do this with a bitwise comparison of the generated tgz files. This works for charts without dependencies, but it is inconsistent for charts with dependencies.

For the setup (Using v2.8.1):

charts
├── child1
│   └── Chart.yaml
├── child2
│   └── Chart.yaml
├── child3
│   └── Chart.yaml
└── parent
    ├── Chart.yaml
    └── requirements.yaml

With charts:

# child{1..3}/Chart.yaml
name: child{1..3}
version: 1.0.0

# parent/Chart.yaml
name: parent
version: 1.0.0

# parent/requirements.yaml
dependencies:
- name: child1
  repository: file://../child1
  version: "*"
- name: child2
  repository: file://../child2
  version: "*"
- name: child3
  repository: file://../child3
  version: "*"

Running:

# working dir: parent
$ helm dep update
$ for i in {1..1000}; do helm package . && sha256sum parent-1.0.0.tgz && rm parent-1.0.0.tgz; done

produces several (3, after a significant number of iterations) different shas. The shas also appear to be non-uniformly distributed (e.g. 1 sha appears 70% of the time).

My guess is that https://github.com/kubernetes/helm/blob/master/pkg/chartutil/save.go#L160 is iterating over dependencies in a non-deterministic order, thus producing different tar files.

The text was updated successfully, but these errors were encountered:

bacongobbler · 2018-03-05T23:18:11Z

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. There is a way to disable this header, but idk if we'd be sacrificing something by stripping the modtime header.

If you gunzip the .tgz, is the shasum identical between tarballs?

cmaher · 2018-03-05T23:24:53Z

gunziping the tars produces different tarballs. There still appear to be 3 different shasums.

bacongobbler · 2018-03-05T23:34:15Z

Following up on my previous comment, you can reproduce this yourself at home:

><> helm fetch stable/traefik
><> gunzip traefik-1.24.1.tgz 
><> helm fetch stable/traefik
><> shasum -a 256 *
a032f1eba2c54b76d8de38d3763bab5ca5a6383af1156f30caf4595adaec67a0  traefik-1.24.1.tar
ebd78bdbbf63f557db8646c6351bfeeac849951334d4cbfc103ecc6bb1b170c5  traefik-1.24.1.tgz

So in this example, I've shown that I've got stable/traefik, both in compressed and decompressed versions from the official stable/traefik chart. If I gzip this up, we should be able to assert that we come up with the same shasum because the contents are the same, right?

Wrongo.

><> gzip traefik-1.24.1.tar 
><> shasum -a 256 *
144eaa108aff820dd754e16732bbacd29accb41954d6249b4111623587fae415  traefik-1.24.1.tar.gz
ebd78bdbbf63f557db8646c6351bfeeac849951334d4cbfc103ecc6bb1b170c5  traefik-1.24.1.tgz

But the shasums of both the recently-gzipped tarball and the old shasum are still identical.

><> gunzip traefik-1.24.1.tar.gz 
><> mv traefik-1.24.1.tar traefik-1.24.1.tar.1
><> gunzip traefik-1.24.1.tgz 
><> mv traefik-1.24.1.tar traefik-1.24.1.tar.2
><> shasum -a 256 *
a032f1eba2c54b76d8de38d3763bab5ca5a6383af1156f30caf4595adaec67a0  traefik-1.24.1.tar.1
a032f1eba2c54b76d8de38d3763bab5ca5a6383af1156f30caf4595adaec67a0  traefik-1.24.1.tar.2

So in other words, if you want a deterministic shasum of the contents of the chart, I'd suggest decompressing the packages first before checking the shasum.

Would that work for you?

bmperrea · 2018-03-06T13:50:09Z

The timestamp issue in the default gzip settings appears to be irrelevant since there are only a few unique shas that appear in thousands of tests on helm package (whereas the shas from the gzip example appear to be purely random). It looks like writeToTar in pkg/chartutil/save.go specifies its own header here: https://github.com/kubernetes/helm/blob/master/pkg/chartutil/save.go#L205.

Perhaps sorting the dependencies in a deterministic manner before serialization is all that is needed, but any help on where to put the sort would be appreciated.

For now a workaround is to do a file diff on the decompressed packages after removing the dependency tars. This won't catch differences in dependencies except version differences (which can happen for local dependencies, e.g.), but will catch most differences until this can be patched.

bacongobbler · 2018-03-06T21:33:31Z

I was unable to reproduce this behaviour using a stable chart. Can you provide a sample chart that produces this behaviour?

My steps to test this:

$ helm fetch --untar stable/traefik
$ for i in {1..1000}; do helm package traefik/ && mv traefik-1.24.1.tgz traefik-1.24.1.tgz.$i; done
$ shasum -a 256 *.tgz* | awk '{print $1}' | uniq
ebd78bdbbf63f557db8646c6351bfeeac849951334d4cbfc103ecc6bb1b170c5

Every invocation of helm package returned a consistent shasum.

/shrug

cmaher · 2018-03-07T14:59:44Z

https://github.com/cmaher/nondeterministic-charts demonstrates this using Client: &version.Version{SemVer:"v2.8.1", GitCommit:"6af75a8fd72e2aa18a2b278cfe5c7a1c5feca7f2", GitTreeState:"clean"}

I don't think stable/traefik is going to be affected by this, because it doesn't have any dependencies.

fejta-bot · 2018-06-06T01:28:21Z

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

fejta-bot · 2018-07-06T02:13:12Z

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

jeff-knurek · 2018-07-18T11:08:06Z

I found out a way to reproduce this. One thing that seems to be helpful in reproducing is having more than one dependency in the requirements file. Also, the large the values.yaml file the easier it is to reproduce as well.

spinnaker is an example stable chart to reproduce:

mkdir pkgs
cd spinnaker
helm dep up
for i in {1..30}; do helm package . && mv spinnaker-0.5.0.tgz ../pkgs/spinnaker-0.5.0.tgz.$i; done
cd ../pkgs
shasum -a 256 *.tgz* | awk '{print $1}' | uniq

jeff-knurek · 2018-07-18T11:08:27Z

/remove-lifecycle rotten

diclophis · 2018-12-06T20:06:46Z

We have been able to reproduce this issue with some of our local charts as well.

adrian-gierakowski · 2019-02-27T16:18:07Z

The problem definitely manifests itself on macOS. None of the suggestions mentioned in this tread solve the issues. I've created a repo to demonstrate the problem and a workaround: https://github.com/adrian-gierakowski/helm-package-sha-test.

Michael-Sinz · 2019-08-27T14:57:30Z

The problem is due to the order of entries in the tar file. It is not a gzip issue but rather an issue that the two tar files, while the same size, actually have the files within them in a different order.

The issue is that the POSIX directory enumeration API does not define a specific order for file names to be returned. There may be a "common" order but since sorting/ordering is not something that can be done generically (it is locale/user specific), the core filesystems are not forced to provide a consistent order. Result orders may depend on available cache entries or order of data returned from elevator algorithms that read from the disk or a number of other out-of-order execution behaviors.

We noticed this specifically when multiple sub-charts were involved. The order of the sub-charts in the tar file were sometimes different. One form was more common (70% or so).

Note that we had not noticed this problem until we had a chart that had sub-charts like this one has. That seems to be what triggered the whole problem or ordering within the tar file.

Also note that the two tar files, when extracted, produce exactly the same files and directories - they just are in the tar file in a different order which will cause different hashes.

You can see this with tar -t on each of the helm tgz (or extract tar) files.

$ tar -tzf A/speech-onprem-0.1.5.tgz
speech-onprem/Chart.yaml                                                            
speech-onprem/values.yaml
speech-onprem/templates/NOTES.txt
speech-onprem/templates/tests/test-speech-on-prem-readiness.yaml
speech-onprem/.helmignore
speech-onprem/README.md
speech-onprem/charts/speechToText/Chart.yaml
speech-onprem/charts/speechToText/values.yaml
speech-onprem/charts/speechToText/templates/NOTES.txt
speech-onprem/charts/speechToText/templates/_helpers.tpl
speech-onprem/charts/speechToText/templates/_image.tpl
speech-onprem/charts/speechToText/templates/speechToText-autoscaler.yaml
speech-onprem/charts/speechToText/templates/speechToText-deployment.yaml
speech-onprem/charts/speechToText/templates/speechToText-poddisruption.yaml
speech-onprem/charts/speechToText/templates/speechToText-service.yaml
speech-onprem/charts/textToSpeech/Chart.yaml
speech-onprem/charts/textToSpeech/values.yaml
speech-onprem/charts/textToSpeech/templates/NOTES.txt
speech-onprem/charts/textToSpeech/templates/_helpers.tpl
speech-onprem/charts/textToSpeech/templates/_image.tpl
speech-onprem/charts/textToSpeech/templates/textToSpeech-autoscaler.yaml
speech-onprem/charts/textToSpeech/templates/textToSpeech-deployment.yaml
speech-onprem/charts/textToSpeech/templates/textToSpeech-poddisruption.yaml
speech-onprem/charts/textToSpeech/templates/textToSpeech-service.yaml



$ tar -tzf B/speech-onprem-0.1.5.tgz
speech-onprem/Chart.yaml
speech-onprem/values.yaml
speech-onprem/templates/NOTES.txt
speech-onprem/templates/tests/test-speech-on-prem-readiness.yaml
speech-onprem/.helmignore
speech-onprem/README.md
speech-onprem/charts/textToSpeech/Chart.yaml
speech-onprem/charts/textToSpeech/values.yaml
speech-onprem/charts/textToSpeech/templates/NOTES.txt
speech-onprem/charts/textToSpeech/templates/_helpers.tpl
speech-onprem/charts/textToSpeech/templates/_image.tpl
speech-onprem/charts/textToSpeech/templates/textToSpeech-autoscaler.yaml
speech-onprem/charts/textToSpeech/templates/textToSpeech-deployment.yaml
speech-onprem/charts/textToSpeech/templates/textToSpeech-poddisruption.yaml
speech-onprem/charts/textToSpeech/templates/textToSpeech-service.yaml
speech-onprem/charts/speechToText/Chart.yaml
speech-onprem/charts/speechToText/values.yaml
speech-onprem/charts/speechToText/templates/NOTES.txt
speech-onprem/charts/speechToText/templates/_helpers.tpl
speech-onprem/charts/speechToText/templates/_image.tpl
speech-onprem/charts/speechToText/templates/speechToText-autoscaler.yaml
speech-onprem/charts/speechToText/templates/speechToText-deployment.yaml
speech-onprem/charts/speechToText/templates/speechToText-poddisruption.yaml
speech-onprem/charts/speechToText/templates/speechToText-service.yaml

jdolitsky · 2020-05-27T23:36:07Z

Is this related to dependencies, or is the issue just increasingly more likely to occur the more files a chart contains?

The issue is that the POSIX directory enumeration API does not define a specific order for file names to be returned. There may be a "common" order but since sorting/ordering is not something that can be done generically (it is locale/user specific), the core filesystems are not forced to provide a consistent order. Result orders may depend on available cache entries or order of data returned from elevator algorithms that read from the disk or a number of other out-of-order execution behaviors.

Is there really not a way enforce this order in Go? @Michael-Sinz

Michael-Sinz · 2020-05-28T12:35:28Z

You can write your own code to take the enumeration and sort it. Pick your sort to be consistent across all locales. Unix/Posix does not push costly operations onto all use cases when most cases do not need that - it assumes that you would compose one operation with another to get the desired result.

…

__ Michael Sinz C Architect C <http://midori/> v C Microsoft

________________________________ From: Josh Dolitsky <notifications@github.com> Sent: Wednesday, May 27, 2020 4:36 PM To: helm/helm <helm@noreply.github.com> Cc: Michael Sinz <Michael.Sinz@microsoft.com>; Mention <mention@noreply.github.com> Subject: Re: [helm/helm] `helm package` should produce bitwise-deterministic tar files (#3612) Is this related to dependencies, or is the issue just increasingly more likely to occur the more files a chart contains? The issue is that the POSIX directory enumeration API does not define a specific order for file names to be returned. There may be a "common" order but since sorting/ordering is not something that can be done generically (it is locale/user specific), the core filesystems are not forced to provide a consistent order. Result orders may depend on available cache entries or order of data returned from elevator algorithms that read from the disk or a number of other out-of-order execution behaviors. Is there really not a way enforce this order in Go? @Michael-Sinz<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMichael-Sinz&data=02%7C01%7CMichael.Sinz%40microsoft.com%7C7f787afb198646f162fc08d80296c2ef%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637262193827632571&sdata=5yvN1d7V5r1DYfxWZdVYeawCsSmPCOws73GJ68bY0m8%3D&reserved=0> ― You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhelm%2Fhelm%2Fissues%2F3612%23issuecomment-634999466&data=02%7C01%7CMichael.Sinz%40microsoft.com%7C7f787afb198646f162fc08d80296c2ef%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637262193827632571&sdata=nE1BhhEAVlJaYWnLVFMs3dqW9sd89O%2Bw03m9jZi7IGE%3D&reserved=0>, or unsubscribe<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAIZINKSLFWKEXWDAUN3OGL3RTWPXJANCNFSM4ETXKHGQ&data=02%7C01%7CMichael.Sinz%40microsoft.com%7C7f787afb198646f162fc08d80296c2ef%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637262193827642528&sdata=9D784OITV0hBpmnLnLvUDIByZo%2FevAgnuYKA%2B5blDh4%3D&reserved=0>.

github-actions · 2020-11-22T00:30:30Z

This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.

Michael-Sinz · 2020-11-23T15:57:48Z

Is there no progress on this issue. The lack of deterministic output for constant input is a big problem. It means that helm package is not deterministic and we can not depend on it producing the same results. Imaging if a compiler could make different code for the same source code from run to run - how would you debug such a program?

rjeberhard · 2020-11-23T16:00:29Z

Agreed. We've had to make clumsy workarounds to only package the chart if one of the source files changes. One issue is the embedded time stamps.

bacongobbler · 2020-11-23T16:45:36Z

@Michael-Sinz I have not seen any activity from the community on this bug. Please feel free to work on a fix!

github-actions · 2021-02-24T00:32:28Z

This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.

Michael-Sinz · 2021-03-03T13:29:32Z

We still would like to have deterministic helm chart building. The fact that the same helm chart from the same source tree from the same git hash with the same helm version does not produce deterministic hashes is concerning.

github-actions · 2021-06-03T00:22:53Z

This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.

sathieu · 2021-10-20T01:40:38Z

Deterministic output is the goal of the Reproducible builds project.

It has a recommended tar example:

# requires GNU Tar 1.28+
$ tar --sort=name \
      --mtime="@${SOURCE_DATE_EPOCH}" \
      --owner=0 --group=0 --numeric-owner \
      --pax-option=exthdr.name=%d/PaxHeaders/%f,delete=atime,delete=ctime \
      -cf product.tar build

gz seems to produce reproducible output since 2018.

But as helm uses go libs, maybe the fix is around file order:

helm/pkg/chartutil/save.go

Lines 205 to 228 in f41f46c

    
           	// Save templates 
        
           	for _, f := range c.Templates { 
        
           		n := filepath.Join(base, f.Name) 
        
           		if err := writeToTar(out, n, f.Data); err != nil { 
        
           			return err 
        
           		} 
        
           	} 
        
           	// Save files 
        
           	for _, f := range c.Files { 
        
           		n := filepath.Join(base, f.Name) 
        
           		if err := writeToTar(out, n, f.Data); err != nil { 
        
           			return err 
        
           		} 
        
           	} 
        
           	// Save dependencies 
        
           	for _, dep := range c.Dependencies() { 
        
           		if err := writeTarContents(out, dep, filepath.Join(base, ChartsDir)); err != nil { 
        
           			return err 
        
           		} 
        
           	} 
        
           	return nil 
        
           }

geowalrus4gh · 2022-03-30T07:38:25Z

Hi, we are really waiting for this issue to be fixed. The real advantage of using OCI is to make use of the delta changes in a chart that are only committed to the repository and thus save space at the repository heavily. We find this feature very useful in OCI container images. Without this feature, helm OCI support is will not be full.

hickeyma · 2022-03-30T09:32:51Z

/cc @jdolitsky @scottrigby

dinvlad · 2022-09-20T22:35:51Z

Any updates?

h0tbird · 2022-10-04T14:05:17Z

I can reproduce it like this:

$ helm version
version.BuildInfo{Version:"v3.10.0", GitCommit:"ce66412a723e4d89555dc67217607c6579ffcb21", GitTreeState:"clean", GoVersion:"go1.19.1"}
$ helm create foo
Creating foo
$ for i in {1..10}; do helm package foo >/dev/null; md5sum foo-0.1.0.tgz; sleep 0.5; done
39e2b6bff940ed840873926f271d72f8  foo-0.1.0.tgz
f34d771d8039d77c9b76340c7940ab55  foo-0.1.0.tgz
f34d771d8039d77c9b76340c7940ab55  foo-0.1.0.tgz
afe15ee8c34f069e967e88e70c7bbd29  foo-0.1.0.tgz
afe15ee8c34f069e967e88e70c7bbd29  foo-0.1.0.tgz
7c1b20acd7a9a73944af13fec2303cf0  foo-0.1.0.tgz
7c1b20acd7a9a73944af13fec2303cf0  foo-0.1.0.tgz
16cef47516265bed7f8dbd9ef145042c  foo-0.1.0.tgz
16cef47516265bed7f8dbd9ef145042c  foo-0.1.0.tgz
1532cb3b9a5d828e19d74b034caebace  foo-0.1.0.tgz

I tried setting the GZIP="-n" environment variable with no luck.

dinvlad · 2022-10-04T15:01:16Z

FWIW the example from reproducible builds worked well for me, but that obviously requires custom scripting, which is not ideal.

FrenchBen · 2023-01-12T21:37:30Z

Fix for the above has been pending review/merge. Not sure what the blocker is TBH:
#10178

k8s-ci-robot added the ¯\_(ツ)_/¯ label Mar 6, 2018

adamreese added the question/support label Mar 8, 2018

k8s-ci-robot added the lifecycle/stale label Jun 6, 2018

k8s-ci-robot added lifecycle/rotten and removed lifecycle/stale labels Jul 6, 2018

k8s-ci-robot removed the lifecycle/rotten label Jul 18, 2018

bacongobbler added bug Categorizes issue or PR as related to a bug. and removed question/support ¯\_(ツ)_/¯ labels Jul 18, 2018

jschaul mentioned this issue Dec 6, 2018

helm package is not idempotent when used for a N-dependencies umbrella chart #3264

Closed

bacongobbler mentioned this issue Apr 18, 2019

Comparing helm charts's contents (md5) #5575

Closed

bacongobbler mentioned this issue May 27, 2020

Same chart saved at different times has different digest #8212

Closed

bacongobbler mentioned this issue Jun 25, 2020

Cache chart layers without timestamp #8216

Closed

3 tasks

bacongobbler mentioned this issue Oct 5, 2020

Reproducible chart dependency archives #8850

Closed

github-actions bot added the Stale label Nov 22, 2020

github-actions bot removed the Stale label Nov 26, 2020

github-actions bot added the Stale label Feb 24, 2021

github-actions bot removed the Stale label Mar 4, 2021

jdolitsky mentioned this issue Mar 10, 2021

helm registry: helm chart save on the same tgz package generates a different digest (sha) #9292

Closed

mattfarina mentioned this issue May 25, 2021

Generate reproducible tarball #9674

Closed

3 tasks

github-actions bot added the Stale label Jun 3, 2021

bacongobbler added keep open and removed Stale labels Jun 3, 2021

bacongobbler mentioned this issue Sep 22, 2021

Helm package cannot consistently create the same package #10177

Closed

FrenchBen linked a pull request Sep 23, 2021 that will close this issue

Fix package consistency - retain shasum for the package #10178

Open

3 tasks

joejulian added the in progress label Jan 25, 2023

thbkrkr mentioned this issue Apr 21, 2023

sha256 mismatch for Helm chart eck-operator-2.7.0 elastic/cloud-on-k8s#6714

Closed

danigar mentioned this issue Dec 19, 2023

Helm chart output archive is not reproducible masmovil/bazel-rules#55

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

`helm package` should produce bitwise-deterministic tar files #3612

`helm package` should produce bitwise-deterministic tar files #3612

cmaher commented Mar 5, 2018

bacongobbler commented Mar 5, 2018 •

edited

cmaher commented Mar 5, 2018 •

edited

bacongobbler commented Mar 5, 2018 •

edited

bmperrea commented Mar 6, 2018

bacongobbler commented Mar 6, 2018

cmaher commented Mar 7, 2018 •

edited

fejta-bot commented Jun 6, 2018

fejta-bot commented Jul 6, 2018

jeff-knurek commented Jul 18, 2018

jeff-knurek commented Jul 18, 2018

diclophis commented Dec 6, 2018

adrian-gierakowski commented Feb 27, 2019

Michael-Sinz commented Aug 27, 2019 •

edited

jdolitsky commented May 27, 2020

Michael-Sinz commented May 28, 2020 via email

github-actions bot commented Nov 22, 2020

Michael-Sinz commented Nov 23, 2020

rjeberhard commented Nov 23, 2020

bacongobbler commented Nov 23, 2020

github-actions bot commented Feb 24, 2021

Michael-Sinz commented Mar 3, 2021

github-actions bot commented Jun 3, 2021

sathieu commented Oct 20, 2021

geowalrus4gh commented Mar 30, 2022 •

edited

hickeyma commented Mar 30, 2022

dinvlad commented Sep 20, 2022

h0tbird commented Oct 4, 2022 •

edited

dinvlad commented Oct 4, 2022

FrenchBen commented Jan 12, 2023

helm package should produce bitwise-deterministic tar files #3612

helm package should produce bitwise-deterministic tar files #3612

Comments

cmaher commented Mar 5, 2018

bacongobbler commented Mar 5, 2018 • edited

cmaher commented Mar 5, 2018 • edited

bacongobbler commented Mar 5, 2018 • edited

bmperrea commented Mar 6, 2018

bacongobbler commented Mar 6, 2018

cmaher commented Mar 7, 2018 • edited

fejta-bot commented Jun 6, 2018

fejta-bot commented Jul 6, 2018

jeff-knurek commented Jul 18, 2018

jeff-knurek commented Jul 18, 2018

diclophis commented Dec 6, 2018

adrian-gierakowski commented Feb 27, 2019

Michael-Sinz commented Aug 27, 2019 • edited

jdolitsky commented May 27, 2020

Michael-Sinz commented May 28, 2020 via email

github-actions bot commented Nov 22, 2020

Michael-Sinz commented Nov 23, 2020

rjeberhard commented Nov 23, 2020

bacongobbler commented Nov 23, 2020

github-actions bot commented Feb 24, 2021

Michael-Sinz commented Mar 3, 2021

github-actions bot commented Jun 3, 2021

sathieu commented Oct 20, 2021

geowalrus4gh commented Mar 30, 2022 • edited

hickeyma commented Mar 30, 2022

dinvlad commented Sep 20, 2022

h0tbird commented Oct 4, 2022 • edited

dinvlad commented Oct 4, 2022

FrenchBen commented Jan 12, 2023

`helm package` should produce bitwise-deterministic tar files #3612

`helm package` should produce bitwise-deterministic tar files #3612

bacongobbler commented Mar 5, 2018 •

edited

cmaher commented Mar 5, 2018 •

edited

bacongobbler commented Mar 5, 2018 •

edited

cmaher commented Mar 7, 2018 •

edited

Michael-Sinz commented Aug 27, 2019 •

edited

geowalrus4gh commented Mar 30, 2022 •

edited

h0tbird commented Oct 4, 2022 •

edited