[build] relmeta: add ReleaseMilestone and SecurityPatch definitions
Neal Patel (Gerrit)
Neal Patel has uploaded the change for review![]( "Open in Gerrit")
Commit message
relmeta: add ReleaseMilestone and SecurityPatch definitions
Updates golang/go#76157
Updates golang/go#77214
Updates golang/go#78458
Change diff
diff --git a/relmeta/relmeta.go b/relmeta/relmeta.go
new file mode 100644
index 0000000..dc6d61c
--- /dev/null
+++ b/relmeta/relmeta.go
@@ -0,0 +1,48 @@
+// Copyright 2026 The Go Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style
+// license that can be found in the LICENSE file.
+
+// Package relmeta aims to improve the
+// coordination and correctness of Go
+// Security Releases.
+//
+// Any API described by this package is
+// meant for internal use only; it is not
+// subject to the Go 1 compatibility promise
+// and may change at any time.
+package relmeta
+
+// ReleaseMilestone describes all of the
+// self-contained patches which are part
+// of a given Go Security Release.
+type ReleaseMilestone struct {
+ ID int64 `yaml:"id"`
+ Patches []*SecurityPatch `yaml:"security_patches"`
+}
+
+// SecurityPatch is a self-contained body
+// of work that addresses a vulnerability.
+type SecurityPatch struct {
+ ID int64 `yaml:"id"`
+ Track GoSecurityTrack `yaml:"track"`
+ Toolchain bool `yaml:"is_toolchain"`
+ Package string `yaml:"package"`
+ Changelists []string `yaml:"changelists"`
+ ReleaseNote string `yaml:"release_note"`
+ TargetedReleases []string `yaml:"target_releases,omitempty"`
+ GitHubIssueID int64 `yaml:"github_issue_id"`
+ Credits []string `yaml:"credits"`
+ CVE string `yaml:"cve"`
+ CWE string `yaml:"cwe"`
+ // TODO(nealpatel): Associate the VulnDB
+ // Report struct once it is exported.
+ // VulnReport vulndb.Report `yaml:"vuln_report"`
+}
+
+type GoSecurityTrack string
+
+const (
+ Public GoSecurityTrack = "PUBLIC"
+ Private GoSecurityTrack = "PRIVATE"
+ Urgent GoSecurityTrack = "URGENT"
+)
Change information
- A relmeta/relmeta.go
Related details
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Neal Patel (Gerrit)
Neal Patel voted Commit-Queue+1![]( "Open in Gerrit")
| Commit-Queue | +1 |
Related details
- Damien Neil
- Dmitri Shuralyov
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Neal Patel (Gerrit)
Neal Patel uploaded new patchset![]( "Open in Gerrit")
- Damien Neil
- Dmitri Shuralyov
- Neal Patel
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Neal Patel (Gerrit)
Neal Patel voted Commit-Queue+1![]( "Open in Gerrit")
| Commit-Queue | +1 |
Related details
- Damien Neil
- Dmitri Shuralyov
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Dmitri Shuralyov (Gerrit)
Dmitri Shuralyov voted and added 4 comments![]( "Open in Gerrit")
Votes added by Dmitri Shuralyov
| Code-Review | +2 |
4 comments
type SecurityPatch struct {I'll note that it's somewhat unclear how exactly values would be represented in some of the fields because they're not documented: for example, `Changelists []string` might be a slice of URLs, or CL numbers encoded as strings, or Gerrit-style `project~number` IDs.
If it is known, adding a bit of field documentation to resolve such ambiguities can be helpful. It might not be known yet, in which case it's fine. Compare with struct field docs for https://pkg.go.dev/golang.org/x/build/internal/task#PromotedAPI or [releaseAnnouncement](https://cs.opensource.google/go/x/build/+/master:internal/task/announce.go;l=39-65;drc=b23b4805217d5381f5537edb6fa118c0b0330945).
Just pointing this out as room for future improvement; it's fine to leave this out of scope until it's a better time to document these specifics.
TargetedReleases []string `yaml:"target_releases,omitempty"`Is it intentional that the yaml name is "target_releases", while the Go struct field has an extra "ed" after "target"?
TargetedReleases []string `yaml:"target_releases,omitempty"`A note about "omitempty": usually this has effect only when encoding, not when decoding. If these structs aren't intended to cover the encoding cases, it can be left out.
Related details
- Damien Neil
- Neal Patel
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Dmitri Shuralyov (Gerrit)
Dmitri Shuralyov voted Code-Review+1![]( "Open in Gerrit")
| Code-Review | +1 |
Related details
- Damien Neil
- Neal Patel
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Neal Patel (Gerrit)
Neal Patel uploaded new patchset![]( "Open in Gerrit")
- TryBots-Pass: LUCI-TryBot-Result+1 by Go LUCI
Related details
- Damien Neil
- Neal Patel
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Neal Patel (Gerrit)
Neal Patel added 3 comments![]( "Open in Gerrit")
type SecurityPatch struct {I'll note that it's somewhat unclear how exactly values would be represented in some of the fields because they're not documented: for example, `Changelists []string` might be a slice of URLs, or CL numbers encoded as strings, or Gerrit-style `project~number` IDs.
If it is known, adding a bit of field documentation to resolve such ambiguities can be helpful. It might not be known yet, in which case it's fine. Compare with struct field docs for https://pkg.go.dev/golang.org/x/build/internal/task#PromotedAPI or [releaseAnnouncement](https://cs.opensource.google/go/x/build/+/master:internal/task/announce.go;l=39-65;drc=b23b4805217d5381f5537edb6fa118c0b0330945).
Just pointing this out as room for future improvement; it's fine to leave this out of scope until it's a better time to document these specifics.
The ambiguity is intentional here. We have an idea, but not a contract yet.
TargetedReleases []string `yaml:"target_releases,omitempty"`A note about "omitempty": usually this has effect only when encoding, not when decoding. If these structs aren't intended to cover the encoding cases, it can be left out.
Yup! This captures the intention for encode case.
TargetedReleases []string `yaml:"target_releases,omitempty"`Neal PatelIs it intentional that the yaml name is "target_releases", while the Go struct field has an extra "ed" after "target"?
It's not; thanks for catching!
Related details
- Damien Neil
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Damien Neil (Gerrit)
Damien Neil voted Code-Review+2![]( "Open in Gerrit")
- Neal Patel
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Neal Patel (Gerrit)
Neal Patel voted Commit-Queue+1![]( "Open in Gerrit")
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Neal Patel (Gerrit)
Neal Patel uploaded new patchset![]( "Open in Gerrit")
- Code-Review: +1 by Dmitri Shuralyov, +2 by Dmitri Shuralyov, +2 by Damien Neil
- TryBots-Pass: LUCI-TryBot-Result+1 by golang...@luci-project-accounts.iam.gserviceaccount.com
Related details
- Damien Neil
- Dmitri Shuralyov
- Dmitri Shuralyov
- Neal Patel
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Neal Patel (Gerrit)
Neal Patel uploaded new patchset![]( "Open in Gerrit")
Related details
- Damien Neil
- Dmitri Shuralyov
- Dmitri Shuralyov
- Neal Patel
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Neal Patel (Gerrit)
Neal Patel voted Commit-Queue+1![]( "Open in Gerrit")
| Commit-Queue | +1 |
Related details
- Damien Neil
- Dmitri Shuralyov
- Dmitri Shuralyov
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Dmitri Shuralyov (Gerrit)
Dmitri Shuralyov added 1 comment![]( "Open in Gerrit")
go 1.26.2Is raising the x/build module minimum requirement from 1.25.0 to 1.26.2 intentional?
Related details
- Damien Neil
- Dmitri Shuralyov
- Neal Patel
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Neal Patel (Gerrit)
Neal Patel added 1 comment![]( "Open in Gerrit")
go 1.26.2Is raising the x/build module minimum requirement from 1.25.0 to 1.26.2 intentional?
It was not intentional. Reverted.
Related details
- Damien Neil
- Dmitri Shuralyov
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Neal Patel (Gerrit)
Neal Patel uploaded new patchset![]( "Open in Gerrit")
- TryBots-Pass: LUCI-TryBot-Result-1 by golang...@luci-project-accounts.iam.gserviceaccount.com
Related details
- Damien Neil
- Dmitri Shuralyov
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Neal Patel (Gerrit)
Neal Patel voted Commit-Queue+1![]( "Open in Gerrit")
| Commit-Queue | +1 |
Related details
- Damien Neil
- Dmitri Shuralyov
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Neal Patel (Gerrit)
Neal Patel voted Commit-Queue+1![]( "Open in Gerrit")
| Commit-Queue | +1 |
Related details
- Damien Neil
- Dmitri Shuralyov
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Neal Patel (Gerrit)
Neal Patel added 1 comment![]( "Open in Gerrit")
go 1.26.2Neal PatelIs raising the x/build module minimum requirement from 1.25.0 to 1.26.2 intentional?
It was not intentional. Reverted.
`go mod tidy` bumps.
Related details
- Damien Neil
- Dmitri Shuralyov
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Dmitri Shuralyov (Gerrit)
Dmitri Shuralyov added 1 comment![]( "Open in Gerrit")
go 1.26.2Neal PatelIs raising the x/build module minimum requirement from 1.25.0 to 1.26.2 intentional?
Neal PatelIt was not intentional. Reverted.
`go mod tidy` bumps.
It's because a requirement on the golang.org/x/vulndb module is added, and that module requires 1.26.2:
Given this is adding a fairly small struct, I don't think it warrants increasing the minimum go language requirement. Perhaps x/vulndb module requirement can be lowered, or if that's really not viable, then maybe maintaining a copy of that struct is less expensive.
The Go release policy is that we support both 1.26 and 1.25 equally, and even though x/build is an internal repo, it's imported by by x/website, so I prefer not to raise its minimum requirement unless we really have no better choice, and it seems it should be easily avoidable here.
Related details
- Damien Neil
- Neal Patel
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Neal Patel (Gerrit)
Neal Patel added 1 comment![]( "Open in Gerrit")
go 1.26.2Neal PatelIs raising the x/build module minimum requirement from 1.25.0 to 1.26.2 intentional?
Neal PatelIt was not intentional. Reverted.
Dmitri Shuralyov`go mod tidy` bumps.
It's because a requirement on the golang.org/x/vulndb module is added, and that module requires 1.26.2:
Given this is adding a fairly small struct, I don't think it warrants increasing the minimum go language requirement. Perhaps x/vulndb module requirement can be lowered, or if that's really not viable, then maybe maintaining a copy of that struct is less expensive.
The Go release policy is that we support both 1.26 and 1.25 equally, and even though x/build is an internal repo, it's imported by by x/website, so I prefer not to raise its minimum requirement unless we really have no better choice, and it seems it should be easily avoidable here.
- Damien Neil
- Dmitri Shuralyov
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Neal Patel (Gerrit)
Neal Patel added 1 comment![]( "Open in Gerrit")
go 1.26.2Neal PatelIs raising the x/build module minimum requirement from 1.25.0 to 1.26.2 intentional?
Neal PatelIt was not intentional. Reverted.
Dmitri Shuralyov`go mod tidy` bumps.
Neal PatelIt's because a requirement on the golang.org/x/vulndb module is added, and that module requires 1.26.2:
Given this is adding a fairly small struct, I don't think it warrants increasing the minimum go language requirement. Perhaps x/vulndb module requirement can be lowered, or if that's really not viable, then maybe maintaining a copy of that struct is less expensive.
The Go release policy is that we support both 1.26 and 1.25 equally, and even though x/build is an internal repo, it's imported by by x/website, so I prefer not to raise its minimum requirement unless we really have no better choice, and it seems it should be easily avoidable here.
Agree.
Reasonable to bump x/vulndb down.
Actually, x/vulndb cannot be bumped down due to how it functions.
Dmitri Shuralyov (Gerrit)
Dmitri Shuralyov added 2 comments![]( "Open in Gerrit")
go 1.26.2Neal PatelIs raising the x/build module minimum requirement from 1.25.0 to 1.26.2 intentional?
Neal PatelIt was not intentional. Reverted.
Dmitri Shuralyov`go mod tidy` bumps.
Neal PatelIt's because a requirement on the golang.org/x/vulndb module is added, and that module requires 1.26.2:
Given this is adding a fairly small struct, I don't think it warrants increasing the minimum go language requirement. Perhaps x/vulndb module requirement can be lowered, or if that's really not viable, then maybe maintaining a copy of that struct is less expensive.
The Go release policy is that we support both 1.26 and 1.25 equally, and even though x/build is an internal repo, it's imported by by x/website, so I prefer not to raise its minimum requirement unless we really have no better choice, and it seems it should be easily avoidable here.
Neal PatelAgree.
Reasonable to bump x/vulndb down.
Actually, x/vulndb cannot be bumped down due to how it functions.
Filed issue #79001 for it.
cloud.google.com/go/cloudbuild v1.15.0These updates are reasonable but a slight preference to break them out into a separate CL, since it's pretty unrelated. Sent you CL 771740.
Related details
- Damien Neil
- Neal Patel
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Neal Patel (Gerrit)
Neal Patel uploaded new patchset![]( "Open in Gerrit")
- TryBots-Pass: LUCI-TryBot-Result+1 by golang...@luci-project-accounts.iam.gserviceaccount.com
Related details
- Damien Neil
- Neal Patel
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Neal Patel (Gerrit)
Neal Patel voted and added 1 comment![]( "Open in Gerrit")
Votes added by Neal Patel
| Commit-Queue | +1 |
1 comment
go 1.26.2Neal PatelIs raising the x/build module minimum requirement from 1.25.0 to 1.26.2 intentional?
Neal PatelIt was not intentional. Reverted.
Dmitri Shuralyov`go mod tidy` bumps.
Neal PatelIt's because a requirement on the golang.org/x/vulndb module is added, and that module requires 1.26.2:
Given this is adding a fairly small struct, I don't think it warrants increasing the minimum go language requirement. Perhaps x/vulndb module requirement can be lowered, or if that's really not viable, then maybe maintaining a copy of that struct is less expensive.
The Go release policy is that we support both 1.26 and 1.25 equally, and even though x/build is an internal repo, it's imported by by x/website, so I prefer not to raise its minimum requirement unless we really have no better choice, and it seems it should be easily avoidable here.
Neal PatelAgree.
Reasonable to bump x/vulndb down.
Dmitri ShuralyovActually, x/vulndb cannot be bumped down due to how it functions.
Filed issue #79001 for it.
- Damien Neil
- Dmitri Shuralyov
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Neal Patel (Gerrit)
Neal Patel uploaded new patchset![]( "Open in Gerrit")
- Dmitri Shuralyov
- Neal Patel
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Neal Patel (Gerrit)
Neal Patel voted Commit-Queue+1![]( "Open in Gerrit")
| Commit-Queue | +1 |
Related details
- Dmitri Shuralyov
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Dmitri Shuralyov (Gerrit)
Dmitri Shuralyov voted and added 3 comments![]( "Open in Gerrit")
Votes added by Dmitri Shuralyov
| Code-Review | +2 |
3 comments
Thanks. Two questions about fields that stood out to me, but I expect you're more familiar with what they're intended to be.
ID int64 `yaml:"id"`Is `ID` right here? I expect it might've intended to be BuganizerID / `buganizer_id` based on [here](https://cs.opensource.google/go/x/build/+/master:internal/task/security_release_coalesce.go;l=155;drc=177d1e91b1c5109b44165e98c7d8a032e07bb6ed) and [here](https://cs.opensource.google/go/x/build/+/master:internal/task/security_release_coalesce_test.go;l=138;drc=177d1e91b1c5109b44165e98c7d8a032e07bb6ed).
TargetedReleases []string `yaml:"target_releases,omitempty"`Is it intentional that the yaml name is "target_releases", while the Go struct field has an extra "ed" after "target"?
It's not; thanks for catching!
This was resolved by adding "ed" to the field name, but is it possible you intended to drop "ed" from the yaml name instead? Asking because both in CL 771721 and in the security-metadata yaml I still see "target_releases" being used, and as a name it seems to make sense (e.g., "the target releases for such and such security fix are go1.4.1 and go1.3.1").
Related details
- Neal Patel
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Dmitri Shuralyov (Gerrit)
Dmitri Shuralyov voted Code-Review+1![]( "Open in Gerrit")
| Code-Review | +1 |
Related details
- Neal Patel
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Neal Patel (Gerrit)
Neal Patel uploaded new patchset![]( "Open in Gerrit")
- TryBots-Pass: LUCI-TryBot-Result+1 by golang...@luci-project-accounts.iam.gserviceaccount.com
Related details
- Neal Patel
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Neal Patel (Gerrit)
Neal Patel added 2 comments![]( "Open in Gerrit")
ID int64 `yaml:"id"`Is `ID` right here? I expect it might've intended to be BuganizerID / `buganizer_id` based on [here](https://cs.opensource.google/go/x/build/+/master:internal/task/security_release_coalesce.go;l=155;drc=177d1e91b1c5109b44165e98c7d8a032e07bb6ed) and [here](https://cs.opensource.google/go/x/build/+/master:internal/task/security_release_coalesce_test.go;l=138;drc=177d1e91b1c5109b44165e98c7d8a032e07bb6ed).
Both ReleaseMilestone.ID and SecurityPatch.ID are intended to be opaque. I'm not sure if that's the right choice?
VulnReport.ID is a string of "GO-YYYY-NNNN" format.
TargetedReleases []string `yaml:"target_releases,omitempty"`Neal PatelIs it intentional that the yaml name is "target_releases", while the Go struct field has an extra "ed" after "target"?
Dmitri ShuralyovIt's not; thanks for catching!
This was resolved by adding "ed" to the field name, but is it possible you intended to drop "ed" from the yaml name instead? Asking because both in CL 771721 and in the security-metadata yaml I still see "target_releases" being used, and as a name it seems to make sense (e.g., "the target releases for such and such security fix are go1.4.1 and go1.3.1").
- Dmitri Shuralyov
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Neal Patel (Gerrit)
Neal Patel voted Commit-Queue+1![]( "Open in Gerrit")
| Commit-Queue | +1 |
Related details
- Dmitri Shuralyov
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |