Go version
go version go1.24.4 linux/amd64
Output of go env in your module/workspace:
AR='ar'
CC='gcc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='g++'
GCCGO='gccgo'
GO111MODULE=''
GOAMD64='v1'
GOARCH='amd64'
GOAUTH='netrc'
GOBIN='/home/kiso/.local/share/mise/installs/go/1.24.4/bin'
GOCACHE='/home/kiso/.cache/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/home/kiso/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build1616535208=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='/home/kiso/s/golang/text/go.mod'
GOMODCACHE='/home/kiso/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/kiso/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/home/kiso/.local/share/mise/installs/go/1.24.4'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/kiso/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/home/kiso/.local/share/mise/installs/go/1.24.4/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.24.4'
GOWORK=''
PKG_CONFIG='pkg-config'
What did you do?
https://go.dev/play/p/Yn4dKzNY2Tr
What did you see happen?
.com <nil>
example.com <nil>
What did you expect to see?
Go's IDNA implementation currently accepts Punycode labels ending with hyphens (e.g., "xn--example-") and produces unexpected results. UTS-46 Revision 33 now specifies these should be treated as errors. https://www.unicode.org/reports/tr46/tr46-33.html#Modifications
This issue was already partially noted as a TODO in Go's IDNA test files: https://github.com/golang/text/blob/master/internal/export/idna/idna10.0.0_test.go
I reported a similar issue in rust-url, which led to the specification being updated. - https://rustsec.org/advisories/RUSTSEC-2024-0421.html - https://bugzilla.mozilla.org/show_bug.cgi?id=1887898
I have a local fix ready and would like to contribute it. Should this be filed against x/text/idna since the relevant code appears to be generated?
Note: I initially reported this to Google Bug Hunters, but was advised to report it on GitHub since it's not a sensitive security issue.
Comment From: gabyhelp
Related Issues
- x/net/idna: separate CheckHyphens from ValidateLabel #41732 (closed)
- x/net/idna: ToUnicode does not correctly handle labels with mixed/uppercase ACE prefixes #48778 (closed)
- x/net/idna: support label separators other than ASCII dot #19603
- x/net/idna: Display returns invalid label for r4---sn-a5uuxaxjvh-gpm6.googlevideo.com. #27059
- x/net/idna: backward compatibility issues with recent change #18567 (closed)
- x/net/idna: apply nameprep normalization algorithm #16501 (closed)
- x/net/idna: backward compatibility issues with change 2 #19821 (closed)
- x/net/idna: context validation #30940
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)
Comment From: kunal5042
/assign I want to contribute to this, can you assign it to me?
Comment From: KageShiron
I have already created a fix for this issue and want to contribute it myself.
The "LibraryProposal" label was added, but I believe this issue also affects functions like http.Get and should be treated as a bug. This behavior is also inconsistent with how other URL libraries handle similar cases. This change would have minimal impact on existing code, as it is unlikely that any programs expect xn--example-.com to be processed as example.com.
Comment From: dmitshur
Thanks for filing the issue. Someone familiar with this package may have more specific comments, but in general please see https://go.dev/doc/contribute on how to send a code change. I added a mention of net/http to the issue title.
CC @neild, @ianlancetaylor.