* fix(provenance): support GnuPG keybox (pubring.kbx) keyrings
Starting with GnuPG 2.1, file-backed public keyrings can use
~/.gnupg/pubring.kbx instead of the legacy pubring.gpg. Helm only read
the legacy format, so chart and plugin verification failed on
installations using the file-backed keybox.
Make the keyring loader format-aware:
- GnuPG keybox (pubring.kbx): extract OpenPGP keyblocks from the
keybox container without adding a dependency. Skip ephemeral blobs,
matching GnuPG's own read behavior.
- ASCII-armored keyrings: load single or concatenated exports.
- Legacy binary packet streams (pubring.gpg): retain the existing path.
defaultKeyring() falls back to pubring.kbx when pubring.gpg is absent.
pubring.gpg keeps precedence when both files exist.
This change covers file-backed public keyrings. It does not read the
SQLite database used by keyboxd, which needs a separate design.
Related to #31836
Signed-off-by: Ruslan Shaydullin <shaydullin.r.d@outlook.com>
* fix(provenance): treat only not-exist as keyring absence in defaultKeyring
A stat error other than 'not exist' (e.g. a permission problem) meant
the file may well be present, but defaultKeyring() skipped past it: an
unreadable pubring.gpg silently lost precedence to pubring.kbx, and the
surfaced error could point at the wrong file. Treat only fs.ErrNotExist
as absence. For any other stat error, return that path unchanged so the
real error surfaces when the keyring is opened.
Signed-off-by: Ruslan Shaydullin <shaydullin.r.d@outlook.com>
---------
Signed-off-by: Ruslan Shaydullin <shaydullin.r.d@outlook.com>
Co-authored-by: George Jenkins <gvjenkins@gmail.com>
If the CLI-side description validation is removed, the unicode/utf8 import becomes unused and should also be dropped.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Signed-off-by: MrJack <36191829+biagiopietro@users.noreply.github.com>
Remove duplicate rollback-with-description.txt fixture that had
identical content to rollback.txt.
Signed-off-by: MrJack <36191829+biagiopietro@users.noreply.github.com>
Add a new --description flag to the helm rollback command that allows
users to specify a custom description explaining why the rollback was
performed. This description is stored in the release metadata.
Changes:
- Add Description field to the Rollback action struct
- Add --description flag to the rollback CLI command
- Add 512 character limit validation for the description
- Default to 'Rollback to <version>' when no description is provided
The description flag is optional and follows the same pattern used by
the install and upgrade commands.
Closes #XXXX
Signed-off-by: MrJack <36191829+biagiopietro@users.noreply.github.com>
`helm upgrade --dependency-update` built its downloader.Manager without a
RegistryClient, unlike the identical literals in install, dependency update,
and dependency build. Resolving an OCI chart dependency whose version is a
range then dereferenced a nil *registry.Client in registry.(*Client).Tags,
panicking the process. Pass the registry client already constructed for the
command, matching install.
Add a regression test that runs `upgrade --dependency-update` against a chart
with an unresolved OCI dependency and asserts the command returns an error
instead of panicking.
Signed-off-by: Gates Wang <9372086+SetagGnaw@users.noreply.github.com>
* fix: enable concurrent status computation to prevent multi-minute delays
Set StatusComputeWorkers=8 on DefaultStatusWatcher for Wait,
WaitWithJobs, and WatchUntilReady. This opts in to the async status
computation added in fluxcd/cli-utils#20, preventing the informer
notification pipeline from being blocked by slow API calls when many
resources are updated simultaneously.
Without this, status computation for resources like Deployments (which
require additional LIST ReplicaSets/Pods calls) runs serially inside
the informer, causing growing delays of 1-3+ minutes when upgrading
many resources at once (e.g., ~20 Deployments via Helm).
Signed-off-by: maplemiao <maplemiao@tencent.com>
* refactor(kube): expose StatusComputeWorkers as a WaitOption
Replace the package-level DefaultStatusComputeWorkers variable with a
WithStatusComputeWorkers WaitOption threaded through waitOptions into
the statusWaiter. This removes global mutable state from pkg/kube and
lets callers opt in explicitly.
SDK consumers (e.g. helm-controller) inherit the zero value, which
preserves the upstream cli-utils synchronous behavior and avoids an
unexpected fan-out of status-compute goroutines when many releases
reconcile concurrently. The Helm CLI continues to enable 8 workers by
default via a shared pkg/cmd/flags.go helper, so install/upgrade/
rollback/uninstall/test users still get the fix for multi-minute
informer stalls out of the box.
Signed-off-by: maplemiao <maplemiao@tencent.com>
* refactor(kube): clamp negative StatusComputeWorkers values to zero
Address review feedback: when a caller passes a negative value to
WithStatusComputeWorkers, coerce it to zero rather than propagating
it to the underlying cli-utils watcher, where the behavior is
undefined. Zero is the safe default and matches the SDK opt-in
contract.
Signed-off-by: maplemiao <maplemiao@tencent.com>
---------
Signed-off-by: maplemiao <maplemiao@tencent.com>
Signed-off-by: Maple Miao <maplemiao@yunzhanghu.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Ruslan Shaydullin
MrJack
Matthieu MOREL
Terry Howe
Robert Sirchia
Matt Farina
Gates Wang
Zhaofeng Miao