<feed xmlns='http://www.w3.org/2005/Atom'>
<title>go, branch go1.26.1</title>
<subtitle>Fork of Go programming language with my patches.</subtitle>
<id>http://git.kilabit.info/go/atom?h=go1.26.1</id>
<link rel='self' href='http://git.kilabit.info/go/atom?h=go1.26.1'/>
<link rel='alternate' type='text/html' href='http://git.kilabit.info/go/'/>
<updated>2026-03-06T00:26:39Z</updated>
<entry>
<title>[release-branch.go1.26] go1.26.1</title>
<updated>2026-03-06T00:26:39Z</updated>
<author>
<name>Gopher Robot</name>
<email>gobot@golang.org</email>
</author>
<published>2026-03-06T00:19:54Z</published>
<link rel='alternate' type='text/html' href='http://git.kilabit.info/go/commit/?id=e87b10ea2a2c6c65b80c4374af42b9c02ac9fb20'/>
<id>urn:sha1:e87b10ea2a2c6c65b80c4374af42b9c02ac9fb20</id>
<content type='text'>
Change-Id: Ia2366ca54412a0e31c3838f71f302e2e7f26260e
Reviewed-on: https://go-review.googlesource.com/c/go/+/752121
Auto-Submit: Gopher Robot &lt;gobot@golang.org&gt;
Reviewed-by: Jakub Ciolek &lt;jakub@ciolek.dev&gt;
TryBot-Bypass: Gopher Robot &lt;gobot@golang.org&gt;
Reviewed-by: Cherry Mui &lt;cherryyz@google.com&gt;
Reviewed-by: Dmitri Shuralyov &lt;dmitshur@google.com&gt;
</content>
</entry>
<entry>
<title>[release-branch.go1.26] crypto/x509: fix name constraint checking panic</title>
<updated>2026-03-06T00:12:58Z</updated>
<author>
<name>Roland Shoemaker</name>
<email>bracewell@google.com</email>
</author>
<published>2026-02-11T22:49:13Z</published>
<link rel='alternate' type='text/html' href='http://git.kilabit.info/go/commit/?id=e792d6aa952dbfdd3e8eac6f7abc3efd9df09030'/>
<id>urn:sha1:e792d6aa952dbfdd3e8eac6f7abc3efd9df09030</id>
<content type='text'>
Apparently we allow empty dNSName SANs (e.g. a domain name of ""), which
causes the excluded domain name wildcard checking to panic, because we
assume names are always non-empty. RFC 5280 appears to say the empty
string should not be accepted, although confusingly refers to this as
" " (a single space). We should probably not allow that when creating
certificates, and possibly when creating them as well (1.27 I guess).

Thanks to Jakub Ciolek for reporting this issue.

Updates #77953
Fixes #77974
Fixes CVE-2026-27138

Change-Id: I4fb213a5450470969a7436cba09b71fd1755a6af
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/3420
Reviewed-by: Neal Patel &lt;nealpatel@google.com&gt;
Reviewed-by: Nicholas Husin &lt;husin@google.com&gt;
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/3621
Reviewed-by: Damien Neil &lt;dneil@google.com&gt;
Reviewed-on: https://go-review.googlesource.com/c/go/+/752083
Reviewed-by: Dmitri Shuralyov &lt;dmitshur@google.com&gt;
TryBot-Bypass: Gopher Robot &lt;gobot@golang.org&gt;
Auto-Submit: Gopher Robot &lt;gobot@golang.org&gt;
Reviewed-by: Cherry Mui &lt;cherryyz@google.com&gt;
</content>
</entry>
<entry>
<title>[release-branch.go1.26] crypto/x509: fix full email constraint matching</title>
<updated>2026-03-06T00:12:54Z</updated>
<author>
<name>Roland Shoemaker</name>
<email>bracewell@google.com</email>
</author>
<published>2026-02-11T23:16:38Z</published>
<link rel='alternate' type='text/html' href='http://git.kilabit.info/go/commit/?id=a761c9ff70fec8e1089897eebd104a8f31cff2d3'/>
<id>urn:sha1:a761c9ff70fec8e1089897eebd104a8f31cff2d3</id>
<content type='text'>
For full email addresses (local@domain), we stored a map between the
case sensitive local portion to the case insensitive domain portion, and
used that to check if a email SAN matched the constraint. This could be
abused, because it was a map[string]string, meaning if any two
constraints had the same local portion but different domains, the second
would overwrite the first.

Change the map from map[string]string to map[rfc2821Mailbox]struct{},
where the domain portion of the mailbox is lowercased. When checking for
a match we then check the parsed mailbox against the map, lowercasing
the domain portion of the query when we initially parse the address.
This gives us the same functionality as before, but without the
possibility of one constraint overwriting another.

Thanks to Jakub Ciolek for reporting this issue.

Updates #77952
Fixes #77973
Fixes CVE-2026-27137

Change-Id: Ia405209be6f3b87cf4ac220a645467418dc41805
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/3440
Reviewed-by: Neal Patel &lt;nealpatel@google.com&gt;
Reviewed-by: Nicholas Husin &lt;husin@google.com&gt;
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/3620
Reviewed-by: Damien Neil &lt;dneil@google.com&gt;
Reviewed-on: https://go-review.googlesource.com/c/go/+/752082
TryBot-Bypass: Gopher Robot &lt;gobot@golang.org&gt;
Auto-Submit: Gopher Robot &lt;gobot@golang.org&gt;
Reviewed-by: Dmitri Shuralyov &lt;dmitshur@google.com&gt;
Reviewed-by: Cherry Mui &lt;cherryyz@google.com&gt;
</content>
</entry>
<entry>
<title>[release-branch.go1.26] html/template: properly escape URLs in meta content attributes</title>
<updated>2026-03-06T00:12:49Z</updated>
<author>
<name>Roland Shoemaker</name>
<email>bracewell@google.com</email>
</author>
<published>2026-01-09T19:12:01Z</published>
<link rel='alternate' type='text/html' href='http://git.kilabit.info/go/commit/?id=994692847a2cd3efd319f0cb61a07c0012c8a4ff'/>
<id>urn:sha1:994692847a2cd3efd319f0cb61a07c0012c8a4ff</id>
<content type='text'>
The meta tag can include a content attribute that contains URLs, which
we currently don't escape if they are inserted via a template action.
This can plausibly lead to XSS vulnerabilities if untrusted data is
inserted there, the http-equiv attribute is set to "refresh", and the
content attribute contains an action like `url={{.}}`.

Track whether we are inside of a meta element, if we are inside of a
content attribute, _and_ if the content attribute contains "url=". If
all of those are true, then we will apply the same URL escaping that we
use elsewhere.

Also add a new GODEBUG, htmlmetacontenturlescape, to allow disabling this
escaping for cases where this behavior is considered safe. The behavior
can be disabled by setting htmlmetacontenturlescape=0.

Updates #77954
Fixes #77972
Fixes CVE-2026-27142

Change-Id: I9bbca263be9894688e6ef1e9a8f8d2f4304f5873
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/3360
Reviewed-by: Neal Patel &lt;nealpatel@google.com&gt;
Reviewed-by: Nicholas Husin &lt;husin@google.com&gt;
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/3643
Reviewed-by: Damien Neil &lt;dneil@google.com&gt;
Reviewed-on: https://go-review.googlesource.com/c/go/+/752081
Auto-Submit: Gopher Robot &lt;gobot@golang.org&gt;
Reviewed-by: Cherry Mui &lt;cherryyz@google.com&gt;
TryBot-Bypass: Gopher Robot &lt;gobot@golang.org&gt;
Reviewed-by: Dmitri Shuralyov &lt;dmitshur@google.com&gt;
</content>
</entry>
<entry>
<title>[release-branch.go1.26] net/url: reject IPv6 literal not at start of host</title>
<updated>2026-03-06T00:12:45Z</updated>
<author>
<name>Ian Alexander</name>
<email>jitsu@google.com</email>
</author>
<published>2026-01-28T20:29:52Z</published>
<link rel='alternate' type='text/html' href='http://git.kilabit.info/go/commit/?id=65c7d7a9fb3a9d1fbf1e702a211b8cc3a7bedb53'/>
<id>urn:sha1:65c7d7a9fb3a9d1fbf1e702a211b8cc3a7bedb53</id>
<content type='text'>
This change rejects IPv6 literals that do not appear at the start of the
host subcomponent of a URL.

For example:
  http://example.com[::1] -&gt; rejects
  http://[::1]            -&gt; accepts

Thanks to Masaki Hara (https://github.com/qnighy) of Wantedly.

Updates #77578
Fixes #77970
Fixes CVE-2026-25679

Change-Id: I7109031880758f7c1eb4eca513323328feace33c
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/3400
Reviewed-by: Neal Patel &lt;nealpatel@google.com&gt;
Reviewed-by: Roland Shoemaker &lt;bracewell@google.com&gt;
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/3622
Reviewed-on: https://go-review.googlesource.com/c/go/+/752080
Auto-Submit: Gopher Robot &lt;gobot@golang.org&gt;
TryBot-Bypass: Gopher Robot &lt;gobot@golang.org&gt;
Reviewed-by: Dmitri Shuralyov &lt;dmitshur@google.com&gt;
Reviewed-by: Cherry Mui &lt;cherryyz@google.com&gt;
</content>
</entry>
<entry>
<title>[release-branch.go1.26] cmd/go: revert update default go directive in mod or work init</title>
<updated>2026-03-04T18:38:52Z</updated>
<author>
<name>Michael Matloob</name>
<email>matloob@golang.org</email>
</author>
<published>2026-02-27T18:03:36Z</published>
<link rel='alternate' type='text/html' href='http://git.kilabit.info/go/commit/?id=e28ac674af90b079a7018ce8275885b3b5366d2a'/>
<id>urn:sha1:e28ac674af90b079a7018ce8275885b3b5366d2a</id>
<content type='text'>
This restores the previous behavior of setting go directive to the toolchain's version as per #77653.

For #77653
Fixes #77860

Change-Id: Ie9d2de025a75f39fd8d6d01776d0cf4e5da954f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/749948
LUCI-TryBot-Result: Go LUCI &lt;golang-scoped@luci-project-accounts.iam.gserviceaccount.com&gt;
Reviewed-by: Dmitri Shuralyov &lt;dmitshur@google.com&gt;
Reviewed-by: Austin Clements &lt;austin@google.com&gt;
</content>
</entry>
<entry>
<title>[release-branch.go1.26] cmd: re-vendor x/tools for Go 1.26.1</title>
<updated>2026-03-03T02:06:21Z</updated>
<author>
<name>Cherry Mui</name>
<email>cherryyz@google.com</email>
</author>
<published>2026-03-02T22:05:16Z</published>
<link rel='alternate' type='text/html' href='http://git.kilabit.info/go/commit/?id=4d1051fdc9425deed04d63d78e073223ea9fa2cd'/>
<id>urn:sha1:4d1051fdc9425deed04d63d78e073223ea9fa2cd</id>
<content type='text'>
Update x/tools vendor to the tip of internal-branch.go1.26-vendor
branch (642dd50), to pull in recent fixes of the modernizer. Done
by

cd GOROOT/cmd
go get golang.org/x/tools@internal-branch.go1.26-vendor
go mod tidy
go mod vendor

Fixes #77766
Fixes #77803
Fixes #77804
Fixes #77805
Fixes #77807
Fixes #77849
Fixes #77899
Fixes #77904

Change-Id: Id7aa8c2247949bdc104898270a4ceb3eee68a818
Reviewed-on: https://go-review.googlesource.com/c/go/+/750761
LUCI-TryBot-Result: Go LUCI &lt;golang-scoped@luci-project-accounts.iam.gserviceaccount.com&gt;
Reviewed-by: Alan Donovan &lt;adonovan@google.com&gt;
</content>
</entry>
<entry>
<title>[release-branch.go1.26] os: avoid escape from Root via ReadDir or Readdir</title>
<updated>2026-02-27T21:48:25Z</updated>
<author>
<name>Damien Neil</name>
<email>dneil@google.com</email>
</author>
<published>2026-02-26T17:54:33Z</published>
<link rel='alternate' type='text/html' href='http://git.kilabit.info/go/commit/?id=8cce3ab20c49a5c3c9fa8e97ad47335c3ccd2620'/>
<id>urn:sha1:8cce3ab20c49a5c3c9fa8e97ad47335c3ccd2620</id>
<content type='text'>
When reading the contents of a directory using
File.ReadDir or File.Readdir, the os.FileInfo was
populated on Unix platforms using lstat.
This lstat call is vulnerable to a TOCTOU race
and could escape the root.

For example:
  - Open the directory "dir" within a Root.
    This directory contains a file named "file".
  - Use File.ReadDir to list the contents of "dir",
    receiving a os.DirEntry for "dir/file".
  - Replace "dir" with a symlink to "/etc".
  - Use DirEntry.Info to retrieve the FileInfo for "dir/file".
    This FileInfo contains information on "/etc/file" instead.

This escape permits identifying the presence or absence of
files outside a Root, as well as retreiving stat metadata
(size, mode, modification time, etc.) for files outside a Root.

This escape does not permit reading or writing to files
outside a Root.

For #77827
Fixes #77834
Fixes CVE-2026-27139

Change-Id: I40004f830c588e516aff8ee593d630d36a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/749480
LUCI-TryBot-Result: Go LUCI &lt;golang-scoped@luci-project-accounts.iam.gserviceaccount.com&gt;
Reviewed-by: Nicholas Husin &lt;husin@google.com&gt;
Reviewed-by: Nicholas Husin &lt;nsh@golang.org&gt;
Auto-Submit: Damien Neil &lt;dneil@google.com&gt;
(cherry picked from commit 657ed934e85dc575aad51356c4b437961e7c1313)
Reviewed-on: https://go-review.googlesource.com/c/go/+/749822
</content>
</entry>
<entry>
<title>[release-branch.go1.26] cmd/compile: ensure StructMake/ArrayMake1 of direct interfaces are unwrapped</title>
<updated>2026-02-26T19:45:11Z</updated>
<author>
<name>Keith Randall</name>
<email>khr@golang.org</email>
</author>
<published>2026-02-11T01:44:08Z</published>
<link rel='alternate' type='text/html' href='http://git.kilabit.info/go/commit/?id=ef041913a827cbd63a23c5029b87991c6e49529e'/>
<id>urn:sha1:ef041913a827cbd63a23c5029b87991c6e49529e</id>
<content type='text'>
Ensures that deeply nested structs that have the underlying shape
of a pointer get unwrapped properly.

Update #77536

Change-Id: I004f424d2c62ec7026281daded9b3d96c021e2e1
Reviewed-on: https://go-review.googlesource.com/c/go/+/747760
Reviewed-by: Mark Freeman &lt;markfreeman@google.com&gt;
LUCI-TryBot-Result: Go LUCI &lt;golang-scoped@luci-project-accounts.iam.gserviceaccount.com&gt;
Reviewed-by: David Chase &lt;drchase@google.com&gt;
(cherry picked from commit 1aa534dbb8970b86b0f4059b7665e3505d145e25)
Reviewed-on: https://go-review.googlesource.com/c/go/+/749460
</content>
</entry>
<entry>
<title>[release-branch.go1.26] cmd/compile: pointer-shaped types are SSAable even if lots of 0-sized fields</title>
<updated>2026-02-26T18:36:00Z</updated>
<author>
<name>Keith Randall</name>
<email>khr@golang.org</email>
</author>
<published>2026-02-11T01:44:08Z</published>
<link rel='alternate' type='text/html' href='http://git.kilabit.info/go/commit/?id=155c25e249cab56f740aa93c81ebcb761dd32290'/>
<id>urn:sha1:155c25e249cab56f740aa93c81ebcb761dd32290</id>
<content type='text'>
Normally we don't SSA-ify variables with types that have more than
4 fields. But we really do want to SSA-ify them if they are pointer
shaped.

An odd case, but the compiler shouldn't barf on them.

Failure probably started with CL 714421.

Fixes #77536

Change-Id: I51ef87676cc31df1e51e164bbd58d58c0ab72436
Reviewed-on: https://go-review.googlesource.com/c/go/+/744280
Reviewed-by: Junyang Shao &lt;shaojunyang@google.com&gt;
LUCI-TryBot-Result: Go LUCI &lt;golang-scoped@luci-project-accounts.iam.gserviceaccount.com&gt;
Reviewed-by: David Chase &lt;drchase@google.com&gt;
(cherry picked from commit 6435bf46c17dccb2eb5f7bab7dd8aa4972252b21)
Reviewed-on: https://go-review.googlesource.com/c/go/+/749421
Reviewed-by: Mark Freeman &lt;markfreeman@google.com&gt;
</content>
</entry>
</feed>
