zarf-dev/zarf

Now that the userspace localhost nodeport proxy was implemented for nftables we test this with one of our e2e suites to verify that the nodeport mode does indeed work with nftables. This should likely happen in the existing kind e2e test as kind is generally the easiest to configure.

Steps to reproduce Pull a package with at least 1 helm chart zarf tools archiver decompress --unarchive-all package.tar.zst out Expected result output folder doesn't contain any .tar, .tar.gz, .tgz Actual Result Helm charts are left archived .tgz Severity/Priority Low Additional Context I haven't looked into behavior around manifests Internal thread with context https://defense-unicorns.slack.com/archives/C06QJAUHWFN/p1783975781001169

Describe what should be investigated or refactored In light of recent comprises in CI Pipelines and other supply chain incidents - it would be good to integrate a static analysis solution that could scan on any change to the actions/workflows files and on a periodic basis (weekly?). Best practices will continue to evolve and having a solution that can surface findings on a deterministic basis (ie a source of truth for new findings) would be a benefit to the project as we do not spend significant amounts of time refining existing actions without reason. Zizmor is one option for conducting this. Additional context I would recommend starting with an imperative analysis and working from highest severity to lowest in multiple PR's with reasoning as to the impact of the change. I fear too little context will create a lot of noise that we won't see errors until post-merge and runtime.

Is your feature request related to a problem? Please describe. Currently the OCI annotations (created from metadata.annotations and the in-built ones) only are added to the manifest, not the index when a Zarf package is published. Some tools however look at the Image Index in front of the manifest to parse this information (particularly for the org.opencontainers.image.* annotations defined by the OCI Spec - an example of this being the GitHub Container Registry which looks at org.opencontainers.image.description to populate a description on the package details page: Describe the behavior you'd like Given I have a package I would like to publish to OCI When I publish that package Then the annotations are added to the OCI manifest and the OCI index Describe alternatives you've considered We could handle annotations differently from manifests or only place them on indexes but this would break other applications that expect these annotations to exist and could break existing user assum

Is your feature request related to a problem? Please describe. With larger packages, if you are upgrading to the latest versions of all the helm charts in your components, it can be quite time consuming to go through each helm chart and find the latest version. Describe the behavior you'd like Given a package with multiple helm charts When a user runs a CLI command Then the tool produces a list of all the latest versions for each of the helm charts, with an optional flag to apply those to the config directly (similar to find-images) Additional context This is a quality of life feature to allow maintainers to keep packages up to date efficiently without needing to extract values from the package config, run a separate helm command for each, and then place the results back into the config.