Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

x/net/idna: ToASCII() mangles long strings #28233

Closed
bnoordhuis opened this issue Oct 16, 2018 · 4 comments
Closed

x/net/idna: ToASCII() mangles long strings #28233

bnoordhuis opened this issue Oct 16, 2018 · 4 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Go1.18

Comments

@bnoordhuis
Copy link

What version of Go are you using (go version)?

go version go1.10.1 linux/amd64

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN=""
GOCACHE="/home/bnoordhuis/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/bnoordhuis/go"
GORACE=""
GOROOT="/usr/lib/go-1.10"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go-1.10/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build029944234=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Contrived test case:

package main

import ("strings"; "golang.org/x/net/idna")

func main() {
	n := 65665
	s := strings.Repeat("x", n) + "\uFFFF"
	// python3 -c 'print(("x"*65665+"\uFFFF").encode("punycode")[65665:])'
	expected := "-1f303716a"
	actual, err := idna.ToASCII(s)
	if err != nil {
		panic(err)
	}
	actual = actual[len("xn--") + n:]
	if actual != expected {
		panic(actual) // prints "-qo7g", not "-1f303716a"
	}
}

What did you expect to see?

An error from idna.ToASCII() or the output that python3's punycode encoder produces.

What did you see instead?

$ go run t.go 
panic: -qo7g

goroutine 1 [running]:
main.main()
        /home/bnoordhuis/src/go/t.go:16 +0x165
exit status 2

The overflow check here does not seem to catch the case where the wraparound is big enough that delta + (m - n) * (h + 1) >= 0.

In the test case, it's 0 + (65535 - 128) * (65665 + 1) == 4295016062 % 2**32 == 48766.

Either the input should be rejected (reasonable, many other punycode encoders do) or it should use int64 arithmetic, like python3 does. Python may be an outlier; I'm not aware of other encoders that behave like that.
@FiloSottile FiloSottile added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Oct 16, 2018
@FiloSottile FiloSottile added this to the Go1.12 milestone Oct 16, 2018
@andybons andybons modified the milestones: Go1.12, Go1.13 Feb 12, 2019
@andybons andybons modified the milestones: Go1.13, Go1.14 Jul 8, 2019
@rsc rsc modified the milestones: Go1.14, Backlog Oct 9, 2019
@gopherbot
Copy link

Change https://golang.org/cl/317731 mentions this issue: internal/export/idna: fix int32 overflows

gopherbot pushed a commit to golang/text that referenced this issue Oct 29, 2021
@TimothyGu @neild
internal/export/idna: fix int32 overflows
86e65b8 
Prefer multiplication (int64(b)*int64(c) > MaxInt32) over division (b >
MaxInt32/c) for overflow checking as it is a little faster on 386, and a
LOT faster on amd64.

For golang/go#28233.

Change-Id: Ibf42529b93b699417781adc7eca6e66474f00bbf
Reviewed-on: https://go-review.googlesource.com/c/text/+/317731
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Damien Neil <dneil@google.com>
@gopherbot
Copy link

Change https://golang.org/cl/360381 mentions this issue: idna: update from x/text

gopherbot pushed a commit to golang/net that referenced this issue Nov 4, 2021
@neild
idna: update from x/text
ce13745 
CL 359634: use nontransitional processing in Go 1.18
CL 317731: fix int32 overflows

Updates golang/go#46001
Updates golang/go#47510
Updates golang/go#28233

Change-Id: I2d9cdf5caa44f7c9b2834a256e7464b6edaae9ef
Reviewed-on: https://go-review.googlesource.com/c/net/+/360381
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
@TimothyGu
Copy link
Contributor

N.B., this has been fixed in 77c473f for Go 1.18.

@dmitshur dmitshur added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Dec 2, 2021
@dmitshur dmitshur modified the milestones: Backlog, Go1.18 Dec 2, 2021
@dmitshur
Copy link
Contributor

dmitshur commented Dec 2, 2021

Thanks @TimothyGu, I'll close this issue then. Please comment if we missed something here, or file a new issue if there's a new problem.

@dmitshur dmitshur closed this as completed Dec 2, 2021
xhit pushed a commit to xhit/text that referenced this issue Oct 10, 2022
@TimothyGu @xhit
internal/export/idna: fix int32 overflows
a081df5 
Prefer multiplication (int64(b)*int64(c) > MaxInt32) over division (b >
MaxInt32/c) for overflow checking as it is a little faster on 386, and a
LOT faster on amd64.

For golang/go#28233.

Change-Id: Ibf42529b93b699417781adc7eca6e66474f00bbf
Reviewed-on: https://go-review.googlesource.com/c/text/+/317731
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Damien Neil <dneil@google.com>
@golang golang locked and limited conversation to collaborators Dec 2, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Go1.18
Development

No branches or pull requests
7 participants
@rsc @bnoordhuis @andybons @FiloSottile @TimothyGu @dmitshur @gopherbot