Have you ever wondered what it takes to perform a software release of one of the most popular tools in the Kubernetes community? While you may envision a series of complex steps or maybe even some black magic (some of which may be true), the release process is much more organized and streamlined than you may have envisioned. However, until you see it for yourself firsthand, these types of questions will continue to go unfulfilled. Seeing it really is believing it!

Helm is going to be at KubeCon / CloudNativeCon North America in Salt Lake City. There will be something happening each day of the main conference, including:

• Wednesday:
  • At a booth in the project pavilion from 3:15pm - 8pm.
  • At 7pm MST we are planning to cut a release, live.
• Thursday:
  • At a project pavilion booth from 1:45pm - 5pm.
  • Session: Contribfest: Helm 4: The Next Generation of the Kubernetes Package Manager
  • Session: The Path to Helm 4
• Friday:
  • 12:30pm - 2:30pm at the project pavilion

If you want to talk with a maintainer to learn about Helm or just give feedback, the project pavilion is the perfect place to do that. If you want to learn about Helm v4 the session "The Path to Helm 4" is going to give you an overview. If you want to make your first contributions to Helm, the Contribfest session is a place to get started.

Over four years ago, we introduced Helm 3, a major evolution in Helm's development. And we announced at that time that Helm 2 would receive patches and security updates for a year. We also provided a migration path to Helm 3 from Helm 2 and a tool helm-2to3 to automate migration.

One year later, Helm 2 became unsupported.

Here we are, over 3 years since Helm 2 became unsupported. It would be expected that all users should be migrated to Helm 3 by this time. Following consensus among the Helm org maintainers, we are announcing today the official end of support for the helm-2to3 tool.

We have been saying it for a while now – Helm is "stable software". That should not come as a surprise to anyone familiar with Kubernetes and the surrounding ecosystem as many within the Kubernetes community consider Helm to be the de-facto package manager. The use of Helm is far reaching: from open source community projects, to startups, to Fortune 500 organizations. Helm has become an essential component of build and deployment workflows that handle mission critical workloads.

CVE-2019-25210 was recently filed against the Helm project. This action was completed without engaging the Helm project and working through the documented security process and team. The Helm project was given no notice before the disclosure was released which resulted in the inability to provide an appropriate statement beforehand. This post serves as the response from the Helm project.

Not A Vulnerability In Helm

The Helm project rejects this disclosure’s assertion of a vulnerability within Helm.

Helm 3.13 brings some significant and useful changes for Helm users. This ranges from longtime bugs being fixed to some new features that can have an impact on performance.

Dry-run & Template Can Connect To Servers

The dry-run feature on install and upgrade, and Helm template has not been able to communicate with Kubernetes servers. This is for security and because Helm template was designed for template rendering alone.

With Helm 3.13, there is now an opt-in option to communicate with Kubernetes by setting --dry-run=server. This tells Helm to communicate with the server for gathering information but not to perform updates. This flag also works on helm template. If you use --dry-run without setting a value it works as it did before.

Helm introduced full support for storing charts within OCI registries as a distribution method beginning in version 3.8, and while this feature has been available for some time now, there is more underneath the hood than one may realize to make this capability all possible. A number of concepts, working in unison, make it possible to store content aside from traditional container images within OCI registries. This article will explore one of these important concepts, Media Types, their purpose, and how Helm’s own set of Media Types make it possible to extend the storage of charts beyond standard chart repositories to OCI registries.

In the past year, the team at Ada Logics has worked on integrating continuous fuzzing into the Helm core project. This was an effort focused on improving the security posture of Helm and ensuring a continued good experience for Helm users. The fuzzing integration involved enrolling Helm in the OSS-Fuzz project and writing a set of fuzzers that further enriches the test coverage of Helm. In total, 38 fuzzers were written, and nine bugs were found (with eight fixed so far), demonstrating the work’s value for Helm both short term and long term. All fuzzers were implemented by way of Go-fuzz and are run daily by OSS-Fuzz against the latest Helm commit to make sure Helm is continuously fuzz tested. The full report of the engagement can be found here.

The Helm project is happy to welcome yxxhero as our newest maintainer for the helm-www repo!

The Helm maintainers are excited to be headed to KubeCon + CloudNativeCon NA '22 in Detroit, MI in a couple of weeks! As always, there will be a few different places you can find us!