Skip to content

Commit 9dd221f

Browse files
gjenkins8gjenkins8
committed
retest
Signed-off-by: George Jenkins <gvjenkins@gmail.com>
1 parent 14dcca8 commit 9dd221f

12 files changed

Lines changed: 614 additions & 0 deletions

File tree

‎skills/hip-author-workspace/iteration-2/feature-hip/eval_metadata.json‎

Lines changed: 31 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,31 @@
1+
{
2+
"eval_id": 0,
3+
"eval_name": "feature-hip",
4+
"prompt": "I want to write a HIP for adding native support for chart signing using Sigstore/cosign instead of the current PGP-based provenance system.",
5+
"assertions": [
6+
{
7+
"name": "valid_preamble",
8+
"description": "Valid YAML frontmatter with hip: 9999, type: feature, status: draft"
9+
},
10+
{
11+
"name": "all_sections_present",
12+
"description": "All 11 required sections present"
13+
},
14+
{
15+
"name": "abstract_under_100_words",
16+
"description": "Abstract is under 100 words (target: ~50, testing conciseness improvement)"
17+
},
18+
{
19+
"name": "total_under_2500_words",
20+
"description": "Total document under 2500 words (iteration-1 was 2915; testing whether length guidance reduces verbosity)"
21+
},
22+
{
23+
"name": "backwards_compat_addresses_prov",
24+
"description": "Backwards compat references .prov/PGP migration"
25+
},
26+
{
27+
"name": "no_mailing_list_reference",
28+
"description": "Does NOT reference cncf-helm mailing list as primary vetting channel (should reference #helm-dev Slack instead)"
29+
}
30+
]
31+
}

‎skills/hip-author-workspace/iteration-2/feature-hip/with_skill/grading.json‎

Lines changed: 36 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,36 @@
1+
{
2+
"eval_name": "feature-hip",
3+
"variant": "with_skill",
4+
"expectations": [
5+
{
6+
"text": "valid_preamble",
7+
"passed": true,
8+
"evidence": "Preamble valid with hip:9999, status:draft"
9+
},
10+
{
11+
"text": "all_sections_present",
12+
"passed": true,
13+
"evidence": "All 11 sections present"
14+
},
15+
{
16+
"text": "abstract_under_100_words",
17+
"passed": true,
18+
"evidence": "Abstract is 47 words"
19+
},
20+
{
21+
"text": "total_under_2500_words",
22+
"passed": true,
23+
"evidence": "Total is 844 words"
24+
},
25+
{
26+
"text": "backwards_compat_addresses_prov",
27+
"passed": true,
28+
"evidence": "Backwards compat references .prov/PGP"
29+
},
30+
{
31+
"text": "no_mailing_list_reference",
32+
"passed": true,
33+
"evidence": "No mailing list as primary channel"
34+
}
35+
]
36+
}

‎skills/hip-author-workspace/iteration-2/feature-hip/with_skill/outputs/hip-9999.md‎

Lines changed: 123 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,123 @@
1+
---
2+
hip: 9999
3+
title: "Sigstore/Cosign Chart Signing"
4+
authors: [ "User Name <user@example.com>" ]
5+
created: "2026-05-30"
6+
type: "feature"
7+
status: "draft"
8+
---
9+
10+
## Abstract
11+
12+
This proposal adds native Sigstore/cosign-based signing and verification for Helm charts as an alternative to the current PGP-based provenance system. Cosign uses keyless signing via OIDC identity, eliminating the need for manual key management and aligning Helm with the signing standard already adopted across the container ecosystem.
13+
14+
## Motivation
15+
16+
### Current Limitations
17+
18+
Helm's existing chart signing relies on PGP-based `.prov` files. This requires chart authors to generate PGP keys, distribute public keys out-of-band, and manage key lifecycle. The complexity means very few charts in the ecosystem are actually signed, undermining the security that provenance was designed to provide.
19+
20+
### Real-World Impact
21+
22+
Platform teams building secure software supply chains cannot enforce chart verification policies because so few charts carry signatures. CI/CD pipelines that verify container images with cosign must use an entirely separate trust model for the Helm charts that deploy those same images. This inconsistency creates gaps in supply chain security.
23+
24+
### Who Is Affected
25+
26+
Chart authors who want to sign but find PGP tooling burdensome, cluster operators who want to enforce verification policies, and platform teams building end-to-end supply chain security with Sigstore.
27+
28+
### Existing Workarounds
29+
30+
Some teams wrap `cosign sign-blob` around packaged `.tgz` files and store signatures externally, but this is ad-hoc, not discoverable, and unsupported by `helm verify`.
31+
32+
## Rationale
33+
34+
### Why Cosign over PGP
35+
36+
PGP key management is the primary barrier to chart signing adoption. Cosign's keyless mode uses OIDC identity providers (GitHub Actions, Google, Microsoft), removing the need to generate, store, and distribute keys. The container ecosystem has already standardized on Sigstore through projects like Kubernetes itself, which signs releases with cosign.
37+
38+
### Why Native Integration
39+
40+
External wrapper scripts cannot integrate with `helm install --verify` or OCI registry workflows. Native support means signatures are discoverable and verifiable through standard Helm commands, which is essential for policy enforcement.
41+
42+
## Specification
43+
44+
### CLI Flags
45+
46+
Signing is added to `helm package` and `helm push`:
47+
48+
```
49+
helm package mychart/ --cosign-sign
50+
helm package mychart/ --cosign-sign --cosign-key cosign.key
51+
helm push mychart-1.0.0.tgz oci://registry.example.com/charts --cosign-sign
52+
```
53+
54+
Verification is added to `helm install`, `helm pull`, and `helm verify`:
55+
56+
```
57+
helm install myrelease oci://registry.example.com/charts/mychart --cosign-verify
58+
helm pull oci://registry.example.com/charts/mychart --cosign-verify
59+
helm verify mychart-1.0.0.tgz --cosign
60+
```
61+
62+
When `--cosign-sign` is used without `--cosign-key`, keyless mode is used via OIDC identity. When `--cosign-key` is provided, the specified private key is used.
63+
64+
### Signature Storage
65+
66+
For OCI-stored charts, cosign signatures are stored as a separate tag in the same repository following the cosign convention (`sha256-<digest>.sig`). This is consistent with how container image signatures work and requires no changes to registry infrastructure.
67+
68+
For file-based charts, a `.cosign.sig` file is produced alongside the `.tgz`, similar to the existing `.prov` file.
69+
70+
### Verification Behavior
71+
72+
| Flag | Behavior |
73+
|------|----------|
74+
| `--cosign-verify` | Verify cosign signature; fail if missing or invalid |
75+
| `--verify` (existing) | Unchanged; verifies PGP `.prov` file |
76+
| Both flags | Both signatures must be present and valid |
77+
| Neither | No verification (current default behavior) |
78+
79+
### Transparency Log
80+
81+
When keyless signing is used, an entry is recorded in the Rekor transparency log by default. This can be disabled with `--cosign-no-tlog` for air-gapped environments.
82+
83+
### Configuration
84+
85+
Environment variables follow cosign conventions:
86+
87+
- `COSIGN_KEY` -- path to a cosign private key
88+
- `COSIGN_CERTIFICATE` -- path to a signing certificate
89+
- `COSIGN_REKOR_URL` -- custom Rekor transparency log URL
90+
91+
## Backwards Compatibility
92+
93+
This proposal is purely additive. Existing PGP-based `--sign`, `--verify`, and `.prov` file workflows remain unchanged. Cosign support uses new, separate flags and does not alter default behavior.
94+
95+
## Security Implications
96+
97+
This proposal improves Helm's security posture by making chart signing practical. Keyless signing via OIDC ties signatures to verifiable identities. The Rekor transparency log provides a tamper-evident record of all signing events. The cosign verification model is well-audited as part of the Sigstore project under the OpenSSF.
98+
99+
## How to Teach This
100+
101+
Documentation should add a "Signing Charts with Cosign" guide alongside the existing provenance documentation. The lead example should show keyless signing in a GitHub Actions workflow, since that is the most common CI/CD environment. Users familiar with `cosign sign` for container images will find the Helm flags analogous.
102+
103+
## Reference Implementation
104+
105+
No implementation exists yet. The work involves integrating the `sigstore/cosign` Go library into the Helm CLI and adding signature handling to the OCI push/pull paths.
106+
107+
## Rejected Ideas
108+
109+
- **Replacing PGP entirely** -- Too disruptive for existing users who have PGP workflows. Cosign is offered alongside PGP, not as a replacement.
110+
- **Storing signatures inside the OCI manifest** -- This would require custom manifest handling and reduce compatibility with standard registry tooling. Using cosign's standard tag-based approach is simpler and better supported.
111+
- **Notation (CNCF Notary Project)** -- While also a CNCF project, cosign has significantly wider ecosystem adoption and simpler UX, particularly for keyless signing.
112+
113+
## Open Issues
114+
115+
- Should `helm install` support a configuration option to require cosign verification by default, or should this be left to policy tools like Kyverno and OPA Gatekeeper?
116+
117+
## References
118+
119+
- [Sigstore](https://www.sigstore.dev/)
120+
- [Cosign Documentation](https://docs.sigstore.dev/cosign/overview/)
121+
- [Helm Provenance and Integrity](https://helm.sh/docs/topics/provenance/)
122+
- [HIP-0006: OCI Support](https://github.com/helm/community/blob/main/hips/hip-0006.md)
123+
- [Rekor Transparency Log](https://docs.sigstore.dev/rekor/overview/)

‎skills/hip-author-workspace/iteration-2/feature-hip/with_skill/timing.json‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
{"total_tokens": 50240, "duration_ms": 115089, "total_duration_seconds": 115.1}

‎skills/hip-author-workspace/iteration-2/process-hip/eval_metadata.json‎

Lines changed: 31 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,31 @@
1+
{
2+
"eval_id": 1,
3+
"eval_name": "process-hip",
4+
"prompt": "I think we should create a formal process for how Helm handles security embargoes and coordinated disclosure with downstream distributors.",
5+
"assertions": [
6+
{
7+
"name": "valid_preamble",
8+
"description": "Valid YAML frontmatter with hip: 9999, type: process, status: draft"
9+
},
10+
{
11+
"name": "all_sections_present",
12+
"description": "All 11 required sections present"
13+
},
14+
{
15+
"name": "abstract_under_100_words",
16+
"description": "Abstract is under 100 words (target: ~50)"
17+
},
18+
{
19+
"name": "total_under_2500_words",
20+
"description": "Total document under 2500 words (iteration-1 was 2633)"
21+
},
22+
{
23+
"name": "references_security_md",
24+
"description": "References existing SECURITY.md"
25+
},
26+
{
27+
"name": "no_code_in_spec",
28+
"description": "Specification defines process steps, not code"
29+
}
30+
]
31+
}

‎skills/hip-author-workspace/iteration-2/process-hip/with_skill/grading.json‎

Lines changed: 41 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,41 @@
1+
{
2+
"eval_name": "process-hip",
3+
"variant": "with_skill",
4+
"expectations": [
5+
{
6+
"text": "valid_preamble",
7+
"passed": true,
8+
"evidence": "Preamble valid with hip:9999, status:draft"
9+
},
10+
{
11+
"text": "all_sections_present",
12+
"passed": true,
13+
"evidence": "All 11 sections present"
14+
},
15+
{
16+
"text": "abstract_under_100_words",
17+
"passed": true,
18+
"evidence": "Abstract is 49 words"
19+
},
20+
{
21+
"text": "total_under_2500_words",
22+
"passed": true,
23+
"evidence": "Total is 801 words"
24+
},
25+
{
26+
"text": "type_is_process",
27+
"passed": true,
28+
"evidence": "type is process"
29+
},
30+
{
31+
"text": "references_security_md",
32+
"passed": true,
33+
"evidence": "References SECURITY.md"
34+
},
35+
{
36+
"text": "no_code_in_spec",
37+
"passed": true,
38+
"evidence": "Spec correctly avoids code"
39+
}
40+
]
41+
}

‎skills/hip-author-workspace/iteration-2/process-hip/with_skill/outputs/hip-9999.md‎

Lines changed: 120 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,120 @@
1+
---
2+
hip: 9999
3+
title: "Security Embargo and Coordinated Disclosure Process"
4+
authors: [ "George Jenkins" ]
5+
created: "2026-05-30"
6+
type: "process"
7+
status: "draft"
8+
---
9+
10+
## Abstract
11+
12+
This proposal establishes a formal process for managing security embargoes and coordinating vulnerability disclosure with downstream distributors who package Helm. It defines an embargo timeline, a downstream notification list with eligibility criteria, and participant obligations so that patched releases across the ecosystem ship simultaneously when a CVE goes public.
13+
14+
## Motivation
15+
16+
### Current Limitations
17+
18+
Helm's SECURITY.md documents reporting, triage, and public disclosure but contains no process for pre-disclosure coordination with downstream packagers. When the security team publishes a fix, distributors learn about it simultaneously with the public and must scramble to rebuild and ship.
19+
20+
### Real-World Impact
21+
22+
Users who install Helm through Linux distributions (Fedora, Debian, Alpine), cloud providers, or package managers (Homebrew, Chocolatey) remain vulnerable for hours or days after a CVE is published while downstream maintainers react. This gap is avoidable with advance notice.
23+
24+
### Who Is Affected
25+
26+
Distribution maintainers are forced into emergency response with no lead time. End users on downstream channels face delayed protection. The security team lacks a repeatable process for coordination.
27+
28+
### Existing Workarounds
29+
30+
Some distributors monitor Helm's release channels closely or rely on informal relationships with maintainers. This is inconsistent, unscalable, and leaves smaller distributors out entirely.
31+
32+
## Rationale
33+
34+
### Why a formal list rather than ad-hoc notification
35+
36+
Ad-hoc emails to known contacts are error-prone and depend on institutional memory. A documented list with eligibility criteria and removal procedures ensures consistency across security team membership changes.
37+
38+
### Why align with Kubernetes's model
39+
40+
Many Helm downstream distributors already participate in the Kubernetes private distributors list. Aligning reduces cognitive overhead and leverages a proven structure, scaled down for Helm's smaller vulnerability volume.
41+
42+
### Why a fixed 7-day embargo window
43+
44+
A fixed default provides predictability for both the security team and distributors. Variable windows add coordination overhead without proportional benefit. Seven days balances preparation time against leak risk.
45+
46+
## Specification
47+
48+
### Downstream Notification List
49+
50+
The Helm project will maintain a private mailing list (`cncf-helm-distros@lists.cncf.io`) for pre-disclosure notification, separate from the inbound reporting list.
51+
52+
### Eligibility Criteria
53+
54+
Applicants must meet all of the following:
55+
56+
1. Actively package and distribute Helm through a publicly available channel
57+
2. Serve a non-trivial user base
58+
3. Have capability to produce patched builds within the embargo window
59+
4. Have no unresolved history of embargo violations
60+
61+
### Application Process
62+
63+
1. Send a request to `cncf-helm-security@lists.cncf.io` with distribution name, packaging description, user base estimate, two security contacts, and agreement to embargo obligations.
64+
2. The security team reviews; approval requires two security team members.
65+
3. Approved applicants are added to the list. Member organizations are published in SECURITY.md.
66+
67+
### Removal
68+
69+
Members are removed for: voluntary withdrawal, embargo violation (immediate removal, 12-month reinstatement wait), or inactivity (failure to respond to two consecutive notifications, removed after 30-day notice).
70+
71+
### Embargo Process
72+
73+
1. **Day 0**: Security team finalizes patch and determines timeline.
74+
2. **Day 0-1**: Notification sent to downstream list with vulnerability description, severity, patch, planned disclosure date, and workarounds.
75+
3. **Days 1-7**: Distributors prepare patched releases privately. No disclosure permitted outside immediate security response teams.
76+
4. **Day 7**: Public disclosure per existing SECURITY.md process. Distributors may publish simultaneously.
77+
78+
### Timeline Adjustments
79+
80+
- Default: 7 calendar days
81+
- Minimum: 2 days (active exploitation or imminent leak)
82+
- Maximum: 14 days (at distributor request if leak risk is low)
83+
84+
### Severity Threshold
85+
86+
The embargo process applies when: CVSS >= 7.0, or the vulnerability enables remote code execution, privilege escalation, or credential disclosure.
87+
88+
## Backwards Compatibility
89+
90+
This proposal is purely additive. The existing reporting and disclosure workflow in SECURITY.md is unchanged. Distributors who do not join the list are unaffected.
91+
92+
## Security Implications
93+
94+
Sharing vulnerability details pre-disclosure increases leak risk. This is mitigated by strict eligibility criteria, embargo violation consequences (removal plus 12-month wait), and a short maximum window of 14 days.
95+
96+
## How to Teach This
97+
98+
SECURITY.md will gain a new "Coordinated Disclosure for Downstream Distributors" section explaining eligibility, application, and obligations. An announcement on the `cncf-helm` mailing list will invite known distributors to apply. Vulnerability reporters need no process changes.
99+
100+
## Reference Implementation
101+
102+
Create the `cncf-helm-distros@lists.cncf.io` mailing list, update SECURITY.md with the new section, and conduct initial outreach to known distributors.
103+
104+
## Rejected Ideas
105+
106+
- **Private GitHub repository for patches** -- rejected because it requires GitHub accounts, provides less granular access control than a mailing list, and diverges from the Kubernetes model.
107+
- **Per-vulnerability opt-in notifications** -- rejected because the extra round-trip adds latency during time-sensitive coordination without meaningful security benefit.
108+
- **Unlimited embargo extensions** -- rejected because open-ended embargoes increase leak risk and delay protection for direct-install users.
109+
110+
## Open Issues
111+
112+
- Should embargo notifications use PGP or a modern alternative like age?
113+
- How should embargo timelines coordinate with Kubernetes when vulnerabilities span both projects?
114+
115+
## References
116+
117+
- [Helm SECURITY.md](https://github.com/helm/community/blob/main/SECURITY.md)
118+
- [Kubernetes Security Release Process](https://kubernetes.io/docs/reference/issues-security/security-release-process/)
119+
- [Kubernetes Private Distributors List](https://github.com/kubernetes/security/blob/master/private-distributors-list.md)
120+
- [Go Security Policy](https://go.dev/security/policy)

‎skills/hip-author-workspace/iteration-2/process-hip/with_skill/timing.json‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
{"total_tokens": 50798, "duration_ms": 105720, "total_duration_seconds": 105.7}

0 commit comments

Comments
 (0)