helm: Helm 3.6.1 breaks "helm pull" with repo/chartname

Helm 3.6.1 breaks helm pull with repo/chartname (after adding the repo with auth).

How to reproduce:

$ helm repo add myrepo https://example.com/myrepo --username *** --password ***
"myrepo" has been added to your repositories
$ helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "myrepo" chart repository
$ helm pull myrepo/mychart
Error: failed to fetch https://example.com/myrepo/mychart-1.0.0.tgz : 401 Unauthorized

Output of helm version:

version.BuildInfo{Version:"v3.6.1", GitCommit:"61d8e8c4a6f95540c15c6a65f36a6dd0a45e7a2f", GitTreeState:"clean", GoVersion:"go1.16.5"}

About this issue

Original URL
State: closed
Created 3 years ago
Reactions: 14
Comments: 24 (16 by maintainers)

Most upvoted comments

IMHO the security patch 3.6.1 was not really tested and skipped some QA steps. It was optimized for speed to fix a long standing security issue. And this is now causing problems.

While I sympathize with your frustration on this issue, the security audit was conducted by a number of members on the security list, including myself. We did not optimize for speed in any form. We identified the issue, tested the fix against all known use cases, then released it once we verified all known cases worked as expected. This took a number of weeks.

To clarify, the scenarios we were aware of include:

relative URLs
Absolute URLs served from the same hostname
Absolute URLs from an alternative domain

We tested using the following examples, using repotest to help:

urls:
  - /charts/mychart-1.0.0.tgz

urls:
  - https://mydomain.com/charts/mychart-1.0.0.tgz

urls:
  - https://some-other-domain.com/charts/mychart-1.0.0.tgz

But we did not test for this (which apparently is accepted input according to this test case in chartmuseum):

urls:
  - charts/mychart-1.0.0.tgz

Had we known this was a valid use case, we would have accounted for it in our testing.

However I do not agree with the notion that Helm 3.6.1 is “utterly broken”. The three scenarios listed above account for a VERY large majority of chart repositories available today.

I do acknowledge that there may be a few uncaught edge cases we failed to address. We’ll accept pull requests to fix those up.

With the patch that I provided I wanted to shorten the time that it will take someone to identify a possible solution. At the moment I’m not able to provide corresponding test cases. Sorry for that. I only did some tests in our CI/CD environments and everything started working again.

Fair enough. We appreciate you taking the time to look into this issue.

If someone has the time to look into this further, we’d appreciate a patch (along with an accompanying test case). Once complete we can schedule a Helm 3.6.2 with the patch.

In the meantime, if everyone could please share their chart repository’s index.yaml files so we can investigate if there are other uncaught edge cases, that would be helpful as well.

Thanks all for understanding.

bacongobbler on Jun 21, 2021

It was added to the 3.6.3 milestone, but moved out - so 3.6.3 is still broken.

richardwhiuk on Aug 27, 2021

Closing as this is fixed. #9886 was added to the 3.6.3 milestone.

mattfarina on Jul 1, 2021

With a little bit of copy & paste from other test cases I was able to add the corresponding test case that simulates a default behavior when using a repository and reference the helm chart with <reponame>/<application>.

The result is https://github.com/helm/helm/pull/9844 .

dol on Jun 22, 2021

Not sure if this helps but it looks like that the url, once discovered from the repositories is not set as url to the options.

I made a small adjustment that resolves the issue: https://github.com/helm/helm/compare/v3.6.1...dol:patch/v3.6.1?expand=1

dol on Jun 17, 2021