Repository: zarf-dev/zarf (Go)

Issue:
Failed to load keyring
### Environment
Device and OS: Microsoft Windows 10 Enterprise
App version: v0.49.0
Kubernetes distro being used: -
Other: -

### Steps to reproduce
1. Create `ZarfPackageConfig` with a component that use a local helm chart. This local helm chart have a dependency (in my case `cloudnative-pg`).
2. Run the command to list images: `zarf dev find-images`

### Expected result
The images are correctly listed.

### Actual Result
Zarf complains about the GPG keyring.

### Visual Proof (screenshots, videos, text, etc)
Console logs:

```
λ zarf dev find-images ./ai-package
2025-03-11 11:16:30 INF using config file location=C:\Users\jrial95\Sources\ai-deployment\zarf-config.toml
2025-03-11 11:16:30 INF using build directory path=./ai-package
2025-03-11 11:16:30 INF processing local helm chart name=ai-platform version=0.1.0 path=components\ai-platform\helm-chart
2025-03-11 11:16:40 ERR unable to find images: unable to package the chart ai-platform: unable to package the "ai-platform" chart: unable to build dependencies for the chart: could not download https://github.com/cloudnative-pg/charts/releases/download/cloudnative-pg-v0.23.1/cloudnative-pg-0.23.1.tgz: failed to load keyring: open C:\Users\202837\.gnupg\pubring.gpg: The system cannot find the file specified.
```

### Severity/Priority
Medium

### Additional Context
None



Discussion: Hey @JRial95 - appreciate the issue. 

Are you able to build this package as-is with `zarf package create`? I am curious if there is any difference in behaviors here. 

Do you happen to have an example for reproducing this? I can attempt to build one based on that output but It would be incredibly valuable if you have a sanitized example. 
The `zarf package create` command produces the same behavior.

I have created a repository with the minimal code needed to reproduce this issue: [JRial95/zarf-issue-3565](https://github.com/JRial95/zarf-issue-3565).
@JRial95  Let me know if you are able to get cnpg operator and a cluster installed with zarf. We were having problems with it.
This is an excellent issue, thank you for the reproducible steps! I was able to get the chart to download using a gpg key, but it was cumbersome, and the current Zarf code assumes that the user has gpg installed. I believe it's also using an outdated gpg key file extension, but I am not 100% sure. 

It seems when we download charts in other situations we never verify. Additionally, Helm requires users to opt into verifying. Given this, we should stop verifying when building Helm dependencies. If users want to verify, we can add a CLI flag in the future for this. 

PR to fix incoming



Fix (patch):
diff --git a/src/internal/packager/helm/repo.go b/src/internal/packager/helm/repo.go
index 32746e6cb6..92a9599844 100644
--- a/src/internal/packager/helm/repo.go
+++ b/src/internal/packager/helm/repo.go
@@ -25,7 +25,6 @@ import (
 	"helm.sh/helm/v3/pkg/getter"
 	"helm.sh/helm/v3/pkg/registry"
 	"helm.sh/helm/v3/pkg/repo"
-	"k8s.io/client-go/util/homedir"
 
 	"github.com/zarf-dev/zarf/src/config"
 	"github.com/zarf-dev/zarf/src/config/lang"
@@ -345,10 +344,6 @@ func (h *Helm) buildChartDependencies() error {
 	}
 
 	h.settings = cli.New()
-	defaultKeyring := filepath.Join(homedir.HomeDir(), ".gnupg", "pubring.gpg")
-	if v, ok := os.LookupEnv("GNUPGHOME"); ok {
-		defaultKeyring = filepath.Join(v, "pubring.gpg")
-	}
 
 	man := &downloader.Manager{
 		Out:            &message.DebugWriter{},
@@ -359,8 +354,7 @@ func (h *Helm) buildChartDependencies() error {
 		RepositoryConfig: h.settings.RepositoryConfig,
 		RepositoryCache:  h.settings.RepositoryCache,
 		Debug:            false,
-		Verify:           downloader.VerifyIfPossible,
-		Keyring:          defaultKeyring,
+		Verify:           downloader.VerifyNever,
 	}
 
 	// Build the deps from the helm chart