#7364·kubevela

[Bug] vela addon registry add --type git accepts an unusable endpoint, then vela addon list panics

Author: roguepikachuCreated Sep 7, 2026Updated Sep 16, 2026
Labelstype/bugeffort/smallarea/addonarea/cli

Is there an existing issue for this?

Searched the open issues, nothing matching.

Affected area

CLI (vela) / Addon

KubeVela version

CLI built from master at e6bbce3fc (go build ./references/cmd/cli/main.go). Controller v1.10.0.

Kubernetes version and distribution

v1.31.5+k3s1, k3d

Describe the bug

vela addon registry add --type git accepts any endpoint without validating it, and a subsequent vela addon list then crashes the CLI with a nil pointer dereference.

Two things combine here.

addAddonRegistry only performs a reachability check when the record has a Helm source, so git, gitlab, gitee and OSS registries are stored unverified:

https://github.com/kubevela/kubevela/blob/e6bbce3fc/references/cli/addon-registry.go#L84

--type git registries are read through the GitHub REST API. createGitHelper builds a gitHelper from whatever utils.Parse returned, and for a non-GitHub URL that leaves Meta.GithubContent nil. readRepo then dereferences it:

https://github.com/kubevela/kubevela/blob/e6bbce3fc/pkg/addon/addon.go#L547

So any endpoint that is not a GitHub URL is accepted at add time and segfaults at read time. A git:// endpoint is the obvious case, since the protocol looks like it ought to work for a git registry, but it is never used: the reader always talks to api.github.com.

To reproduce

  1. Add a git registry with a git:// endpoint. Note that it is accepted:
bash
$ vela addon registry add repro-git --type git \
    --endpoint=git://127.0.0.1:9418/poc.git --path addons
Successfully add an addon registry repro-git
  1. List addons:
bash
$ vela addon list
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x40 pc=0x411e5f4]

goroutine 1 [running]:
github.com/oam-dev/kubevela/pkg/addon.(*gitHelper).readRepo(0x203b7781fe80, {0x0?, 0x203b7656a670?})
	/kubevela/pkg/addon/addon.go:547 +0x34
github.com/oam-dev/kubevela/pkg/addon.(*gitReader).ListAddonMeta(0x203b7680a478)
	/kubevela/pkg/addon/reader_github.go:45 +0x3c
github.com/oam-dev/kubevela/pkg/addon.(*Registry).ListAddonMeta(0x203b7739f478?)
	/kubevela/pkg/addon/source.go:415 +0x44
github.com/oam-dev/kubevela/references/cli.listAddons({0x7fddcb0, 0x82c04e0}, {0x7ff93c8, 0x203b77506a80}, {0x0, 0x0})
	/kubevela/references/cli/addon.go:1002 +0x200

Any non-GitHub HTTP endpoint reaches the same place. The registry is persisted, so every later vela addon list crashes until it is deleted with vela addon registry delete repro-git.

Expected behavior

Two separate fixes, either of which removes the crash:

  1. vela addon registry add should validate a git endpoint the way it validates Helm and OCI ones, and reject an endpoint the GitHub reader cannot use. Ideally with a message saying --type git expects a GitHub URL and that the git protocol is not supported.
  2. createGitHelper should return an error when utils.Parse produced no GithubContent, and readRepo should not dereference it unconditionally. A stored registry from an older version, or a hand-edited ConfigMap, should surface an error rather than crash the CLI.

A panic is also a poor failure mode for one bad registry among several: listAddons deliberately tolerates a registry it cannot read, and that intent is defeated here.

Screenshots or logs

Stack trace above, taken from a CLI built at e6bbce3fc. Paths have been shortened.

Additional context

Recovering from the state needs the registry name, which vela addon registry list can still print because it does not read the registries:

bash
$ vela addon registry delete repro-git

Suggested labels for triage: type/bug, area/cli, area/addon, effort/small.