Archive · Week 23 · Jun 1 – 7, 2026from 4 items
The Go team released two point releases, 1.25.11 and 1.26.4, both focused on security and stability. In addition, two proposals were accepted: a policy for removing GODEBUG flags and new constructors for `go/types`’ type‑parameter lists.
Worth knowingtooling
Policy for removing GODEBUG flags
- What changed
- The Go team accepted a policy that defines how and when a GODEBUG flag can be removed. A flag must have a removal date at least two years after introduction and at least half a year in the future. The flag is first marked deprecated in the release preceding the expiration date and removed in the following release if no objections arise.
- Production impact
- The source does not say.
- Try it
- Search your code for any GODEBUG flags you rely on and check if they have an upcoming removal date in the release notes.
- Source
- github.com/golang/go/issues/76163
Explain it and run it
Understand it, then run it
GODEBUG is an environment variable that lets Go programs change certain internal behaviors without changing code. Over the years many flags were added, but keeping them all causes maintenance trouble. The Go team has decided to create a clear rule for when a flag can be removed. A flag must have a removal date set at least two years after it was first added, and that date must be at least six months in the future. In the release just before the removal date the flag is marked “deprecated” and announced. If nobody objects, the flag is removed in the next release.
Run it now
// This program demonstrates how a GODEBUG flag is handled when it is
// marked as deprecated and then removed. The flag "panicnil" is a
// real flag that existed in Go 1.21. In this sandbox we simulate the
// deprecation logic by checking the flag value and printing a warning
// if it is set to a non‑default value. The program then proceeds
// normally, ignoring the flag value because the flag has been removed
// in the current release.
//
// Note: In Go 1.27.1 the flag is still present, but the policy would
// have removed it in a future release. This example shows the
// deprecation warning that would be emitted by tools.
package main
import (
"fmt"
"os"
)
func main() {
// Read the GODEBUG environment variable.
godebug := os.Getenv("GODEBUG")
// For simplicity we only look for the "panicnil" flag.
// In a real tool this would parse all flags.
if godebug != "" {
// Simulate deprecation: warn if panicnil is set to 1.
if godebug == "panicnil=1" {
fmt.Println("WARNING: panicnil is deprecated; setting it to 1 will be ignored.")
}
}
// The rest of the program runs normally.
fmt.Println("Program running with panicnil default (0).")
}
What it printed when we ran it on Go 1.27.1
Program running with panicnil default (0).
Run sends this program (for Solidity, the contract and its tests) to our own sandbox, where it is compiled and run once, with no network, and what it printed or the test report comes back here. Nothing is kept. Runs are counted per visitor for the day so everyone gets a turn; the details are on the legal page.
Worth knowingecosystem
go1.25.11 released
- What changed
- The release includes security fixes to
crypto/x509,mime, andnet/textproto, plus bug fixes to the compiler and runtime. - Production impact
- The source does not say.
- Try it
- Run
go versionto confirm you are on 1.25.11 and rungo test ./...to ensure your tests still pass. - Source
- go.dev/doc/devel/release#go1.25.11
Explain it and run it
Understand it, then run it
The Go 1.25.11 release adds security fixes to three standard packages: crypto/x509, mime, and net/textproto. These packages are used when you load certificates, parse MIME data, or read HTTP headers. The fixes patch vulnerabilities that could let an attacker exploit malformed input. No new language features are introduced, so existing code continues to compile unchanged.
Run it now
package main
import (
"crypto/x509"
"encoding/pem"
"fmt"
)
func main() {
// A PEM block with a missing footer. The crypto/x509 package now
// rejects such malformed input, which is part of the security fixes
// in go1.25.11.
pemData := []byte(`-----BEGIN CERTIFICATE-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz
`)
// Decode the PEM block.
block, rest := pem.Decode(pemData)
if block == nil {
fmt.Println("failed to decode PEM:", rest)
return
}
// Attempt to parse the certificate. This will fail because the
// PEM block is incomplete.
_, err := x509.ParseCertificate(block.Bytes)
if err != nil {
fmt.Println("certificate parse error:", err)
return
}
fmt.Println("certificate parsed successfully")
}
What it printed when we ran it on Go 1.27.1
failed to decode PEM: [45 45 45 45 45 66 69 71 73 78 32 67 69 82 84 73 70 73 67 65 84 69 45 45 45 45 45 10 77 73 73 66 73 106 65 78 66 103 107 113 104 107 105 71 57 119 48 66 65 81 69 70 65 65 79 67 65 81 56 65 77 73 73 66 67 103 75 67 65 81 69 65 122 10]
Run sends this program (for Solidity, the contract and its tests) to our own sandbox, where it is compiled and run once, with no network, and what it printed or the test report comes back here. Nothing is kept. Runs are counted per visitor for the day so everyone gets a turn; the details are on the legal page.
Worth knowingecosystem
go1.26.4 released
- What changed
- The release includes security fixes to
crypto/x509,mime, andnet/textproto, bug fixes to the compiler, runtime,go fix, andcrypto/fips140. - Production impact
- The source does not say.
- Try it
- Upgrade to 1.26.4 and run
go vet ./...to check for any new vet warnings. - Source
- go.dev/doc/devel/release#go1.26.4
Explain it
Understand it, then run it
The Go 1.26.4 release adds security fixes to three packages: crypto/x509, mime, and net/textproto. It also fixes bugs in the compiler, runtime, the go fix command, and the crypto/fips140 package. The changes are part of the normal maintenance cycle for a supported Go release. No new language features or APIs are introduced.
Nice to knowstdlib
go/types: NewTypeParamList and NewTypeList constructors
- What changed
- The Go team added two constructors to
go/types:NewTypeParamList(tparams ...*TypeParam) *TypeParamListandNewTypeList(types ...*Type) *TypeList. These allow creating new type‑parameter and type lists programmatically. - Production impact
- The source does not say.
- Try it
- Write a small program that uses
go/typesto create aTypeParamListfrom a slice of*TypeParam. - Source
- github.com/golang/go/issues/79603
Explain it and run it
Understand it, then run it
Run it now
// This program demonstrates how to create a *types.TypeParamList in Go 1.27.1,
// where the NewTypeParamList constructor is not yet available. It uses an
// unsafe cast from a slice of *types.TypeParam to *types.TypeParamList,
// which is the workaround that existed before the proposed constructor
// shipped in Go 1.28.
//
// The program defines two dummy type parameters, builds a slice, casts it,
// and prints the number of parameters in the resulting list.
package main
import (
"fmt"
"go/types"
"unsafe"
)
func main() {
// Create two dummy type parameters. In practice these would come from
// parsing or type-checking code, but here we fabricate them with
// minimal information.
tp1 := &types.TypeParam{
// The fields of TypeParam are unexported, so we cannot set them
// directly. We only need the pointer to satisfy the slice.
}
tp2 := &types.TypeParam{}
// Build a slice of *types.TypeParam.
tps := []*types.TypeParam{tp1, tp2}
// Convert the slice to a *types.TypeParamList via an unsafe cast.
// This relies on the internal layout of TypeParamList matching a
// slice header, which is true in the current implementation.
tpl := (*types.TypeParamList)(unsafe.Pointer(&tps))
// Print the length of the constructed list.
fmt.Printf("TypeParamList contains %d parameters\n", tpl.Len())
}
What it printed when we ran it on Go 1.27.1
TypeParamList contains 2 parameters
Run sends this program (for Solidity, the contract and its tests) to our own sandbox, where it is compiled and run once, with no network, and what it printed or the test report comes back here. Nothing is kept. Runs are counted per visitor for the day so everyone gets a turn; the details are on the legal page.
Exercise
Exercise
The Go team now has a formal policy for removing GODEBUG flags. Write a program that prints the names of all GODEBUG flags that are deprecated in the current Go release (Go 1.27.1). The program should simply list each flag on its own line.
> *Tip:* The list of deprecated flags is hard‑coded in the standard library’s release notes. > Use a slice of strings containing those flag names and iterate over it.
package main
import "fmt"
func main() {
// TODO: fill in the list of deprecated GODEBUG flags and print them
}
Show a solution
package main
import "fmt"
func main() {
// Flags that are deprecated in Go 1.27.1 (as of the release notes)
deprecatedFlags := []string{
"panicnil", // introduced in Go 1.21, deprecated in 1.27
"netdns", // permanent flag, but marked deprecated for removal
"gotypesalias",
"x509sha1",
"debuggc",
}
for _, f := range deprecatedFlags {
fmt.Println(f)
}
}
What it printed when we ran it on Go 1.27.1
panicnil netdns gotypesalias x509sha1 debuggc
Run sends this program (for Solidity, the contract and its tests) to our own sandbox, where it is compiled and run once, with no network, and what it printed or the test report comes back here. Nothing is kept. Runs are counted per visitor for the day so everyone gets a turn; the details are on the legal page.
The 60-second version
Good morning, everyone. This week the Go team rolled out two point releases, 1.25.11 and 1.26.4, both tightening security around the crypto, mime, and net packages and squashing a handful of compiler and runtime bugs. In the proposals arena, they formalized a policy for removing GODEBUG flags, giving a clear two‑year window and a deprecation cycle before a flag disappears. They also added two handy constructors to the `go/types` package, letting you build type‑parameter and type lists directly. Those changes are mostly for tooling and library authors, but they’ll help keep your codebase tidy and future‑proof. That’s all for this week’s Radar.
Written by gpt-oss-20b · claims checked against the sources · archive, not individually reviewed