Go 1.3.2 is released

[Andrew Gerrand]

Hi gophers,

We've just released Go version 1.3.2, a minor point release.

This release includes bug fixes to cgo and the crypto/tls package.

    https://golang.org/doc/devel/release.html#go1.3.minor

The crpyto/tls fix addresses a security bug that affects programs that use crypto/tls to implement a TLS server from Go 1.1 onwards. If the server enables TLS client authentication using certificates (this is rare) and explicitly sets SessionTicketsDisabled to true in the tls.Config, then a malicious client can falsely assert ownership of any client certificate it wishes. This issue was discovered internally and there is no evidence of exploitation.

You can download binary and source distributions from the Go web site:

    https://golang.org/dl/

To compile from source using a Mercurial checkout, update to the release with "hg update release" and build as usual.

Thanks to everyone who contributed to the release.

Andrew

[Francisco Dalla Rosa Soares]

Andrew,

Thank you for another release! Keep up the good work guys :)

> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Camilo Aguilar]

Nice, thank you Andrew. I just pulled the latest changes of the release-branch.go1.3 and ran all.bash. However, when I run `go version` I get 1.3.1

go version go1.3.1 darwin/amd64. Am I doing it right?

--

Camilo Aguilar

Software Engineer

http://github.com/c4milo

[Jarod Liu]

got a test fail building from source.

--- FAIL: TestParseInSydney (0.00 seconds)
        format_test.go:201: ParseInLocation(Feb 01 2013 EST, Sydney) = 2013-02-01 00:00:00 +0000 EST, want 2013-02-01 00:00:00 +1100 AEDT
FAIL
FAIL    time    2.515s

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu Utopic Unicorn (development branch)
Release:        14.10
Codename:       utopic

$ hg summary
parent: 20728:85518b1d6f8d go1.3.2 release
 go1.3.2
branch: release-branch.go1.3
commit: (clean)
update: (current)

[Andrew Gerrand]

On 26 September 2014 11:52, Camilo Aguilar <camilo....@gmail.com> wrote:

Nice, thank you Andrew. I just pulled the latest changes of the release-branch.go1.3 and ran all.bash. However, when I run `go version` I get 1.3.1

go version go1.3.1 darwin/amd64. Am I doing it right?

What does "hg identify" say?

[Andrew Gerrand]

On 26 September 2014 12:09, Jarod Liu <liuyu...@gmail.com> wrote:

got a test fail building from source.

Looks like the zone information on your machine is different to what the tests expect. A benign issue, but please file a report at http://golang.org/issue/new with the details of your system, etc.

[jimmy frasche]

On Thu, Sep 25, 2014 at 7:14 PM, Andrew Gerrand <a...@golang.org> wrote:
> Looks like the zone information on your machine is different to what the
> tests expect. A benign issue, but please file a report at
> http://golang.org/issue/new with the details of your system, etc.

I had the same issue (Debian testing) so I deleted the repo and pulled
down a fresh copy and the error went away.

[Harold.Miao]

thanks!!

Andrew Gerrand <a...@golang.org>于2014年9月26日星期五写道：

--

You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Best Regards,
Harold Miao

[rich.a...@gmail.com]

On Thursday, September 25, 2014 8:13:00 PM UTC-5, Andrew Gerrand wrote:

Hi gophers,

We've just released Go version 1.3.2, a minor point release.

Hi Andrew,

This might be a false alarm because I'm using a slightly modified build.go, but I thought I'd share this now before I get pulled away from Go to put out a fire.

Building Go 1.3.2 failed on testing issue7978.  This happened with latest tdm-gcc 32-bit on Windows.

ok      unicode/utf8    0.072s

?       unsafe  [no test files]

# GOMAXPROCS=2 runtime -cpu=1,2,4

ok      runtime 41.469s

# sync -cpu=10

ok      sync    0.321s

# ..\test\bench\go1

ok      _/F_/go13t32/test/bench/go1     2.263s

# ..\misc\cgo\life

# ..\misc\cgo\stdio

# ..\misc\cgo\test

--- FAIL: Test7978 (0.01 seconds)

        issue7978.go:58: bad stack: didn't find runtime.cgocall( in the stack:

                goroutine 74 [syscall]:

                _/F_/go13t32/misc/cgo/test._Cfunc_issue7978c(0x641960)

                        _/F_/go13t32/misc/cgo/test/_test/_obj_test/_cgo_defun.c:

440 +0x37

                _/F_/go13t32/misc/cgo/test.issue7978go()

                        F:/go13t32/misc/cgo/test/issue7978.go:80 +0x2d

                created by _/F_/go13t32/misc/cgo/test.test7978

                        F:/go13t32/misc/cgo/test/issue7978.go:89 +0x89

        issue7978.go:58: bad stack: didn't find runtime.cgocall( in the stack:

                goroutine 74 [syscall]:

                _/F_/go13t32/misc/cgo/test._Cfunc_issue7978c(0x641960)

                        _/F_/go13t32/misc/cgo/test/_test/_obj_test/_cgo_defun.c:

440 +0x37

                _/F_/go13t32/misc/cgo/test.issue7978go()

                        F:/go13t32/misc/cgo/test/issue7978.go:80 +0x2d

                created by _/F_/go13t32/misc/cgo/test.test7978

                        F:/go13t32/misc/cgo/test/issue7978.go:89 +0x89

FAIL

scatter = 004F66A0

hello from C

sqrt is: 0

FAIL    _/F_/go13t32/misc/cgo/test      1.303s

[you fu]

I want update.but  no files .

On Friday, September 26, 2014 9:13:00 AM UTC+8, Andrew Gerrand wrote:

[brainman]

I created an issue about it https://code.google.com/p/go/issues/detail?id=8813

Alex

[N. Riesco - GMail account]

$ hg pull
$ hg update release

[Michael Jones]

I had the same problem Jared mentions both yesterday and still just now.

--- FAIL: TestParseInSydney (0.00 seconds)

format_test.go:201: ParseInLocation(Feb 01 2013 EST, Sydney) = 2013-02-01 00:00:00 +0000 EST, want 2013-02-01 00:00:00 +1100 AEDT

FAIL

FAIL time 2.370s

On Fri, Sep 26, 2014 at 3:28 AM, N. Riesco - GMail account <nicolas...@gmail.com> wrote:

$ hg pull
$ hg update release

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Michael T. Jones | Chief Technology Advocate  | m...@google.com |  +1 650-335-5765

[br...@inbox.com]

Windows 7 64 bits
Mingw64 4.9.1

Runtime Test Failed (while it's ok with 1.3.1) :

runtime.callbackasm1: nosplit stack overflow

120 assumed on entry to runtime.callbackasm1
104 after runtime.callbackasm1 uses 16
96 on entry to runtime.cgocallback_gofunc
88 after runtime.cgocallback_gofunc uses 8
80 on entry to runtime.cgocallbackg
48 after runtime.cgocallbackg uses 32
40 on entry to runtime.exitsyscall
32 after runtime.exitsyscall uses 8
24 on entry to exitsyscallfast
0 after exitsyscallfast uses 24
-8 on entry to runtime.lock

And something similar with runtime.callbackasm...

However my project builds and runs fine.

[Emily Maier]

On 09/26/2014 08:41 AM, 'Michael Jones' via golang-nuts wrote:
> I had the same problem Jared mentions both yesterday and still just now.
>
> --- FAIL: TestParseInSydney (0.00 seconds)
>
> format_test.go:201: ParseInLocation(Feb 01 2013 EST, Sydney) = 2013-02-01
> 00:00:00 +0000 EST, want 2013-02-01 00:00:00 +1100 AEDT
>
> FAIL
>
> FAIL time 2.370s
>
> On Fri, Sep 26, 2014 at 3:28 AM, N. Riesco - GMail account <
> nicolas...@gmail.com> wrote:
>
>> $ hg pull
>> $ hg update release
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an

>> email to golang-nuts...@googlegroups.com.

>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>

I'm getting the same error here as well.

Emily

[Ian Lance Taylor]

It's an unfortunate but unimportant error, due to a change in timezone
data. It's an error in the test, not in the actual package. Details
at http://golang.org/issue/8547.

Ian

[Michael Jones]

Maybe it has something to do with Andrew being in Sydney? ;-)

[Michael Jones]

Applying that patch leads to:

--- FAIL: TestFormatSecondsInTimeZone-8 (0.00 seconds)

format_test.go:515: Format = 1871-01-01T05:33:02-0034:08, want 1871-01-01T05:33:02-00:34:08

format_test.go:515: Format = 1871-01-01T05:33:02+0034:08, want 1871-01-01T05:33:02+00:34:08

format_test.go:515: Format = 1871-01-01T05:33:02+0034:08, want 1871-01-01T05:33:02+00:34:08

FAIL

FAIL time 2.398s

It's a colon problem

"0034:08" vs "00:34:08"

[Ian Lance Taylor]

On Fri, Sep 26, 2014 at 7:50 AM, 'Michael Jones' via golang-nuts
<golan...@googlegroups.com> wrote:
> Applying that patch leads to:
>
> --- FAIL: TestFormatSecondsInTimeZone-8 (0.00 seconds)
>
> format_test.go:515: Format = 1871-01-01T05:33:02-0034:08, want
> 1871-01-01T05:33:02-00:34:08
>
> format_test.go:515: Format = 1871-01-01T05:33:02+0034:08, want
> 1871-01-01T05:33:02+00:34:08
>
> format_test.go:515: Format = 1871-01-01T05:33:02+0034:08, want
> 1871-01-01T05:33:02+00:34:08
>
> FAIL
>
> FAIL time 2.398s
>
>
> It's a colon problem
>
> "0034:08" vs "00:34:08"

I think that one is http://golang.org/issue/8497 .

Ian

[Michael Jones]

Thank you sir.

[br...@inbox.com]

Confirmed : binary release go1.3.2-windows-amd64.zip fails the test : go test -v .\src\pkg\runtime...

[Camilo Aguilar]

camilo@grinch-2 ~/Development/go % hg identify

1a58c0ea234f (release-branch.go1.3)

[Jason Phillips]

Same test failure (and results) on Windows 8.1 x64.

gcc 4.7.2

[jfcg...@gmail.com]

26 Eylül 2014 Cuma 04:13:00 UTC+3 tarihinde Andrew Gerrand yazdı:

Hi gophers,

We've just released Go version 1.3.2, a minor point release.

Hi
I think I get a crash from godoc in Go1.3.2 linux/amd64 when i visit http://localhost:6060/blog/ producing the following message:

2014/09/28 20:44:29 ~/Program/go/blog/content/osconreport.article:26 bad code argument "_"

godoc commandline is
bin/godoc -http :6060 -index -index_files sindex

only osconreport.article file has that kind of image reference:

gophercon.article:.image gophercon/image01.jpg
gophercon.article:.image gophercon/image00.jpg
go-programming-language-turns-two.article:.image go-programming-language-turns-two_gophers.jpg
go-programming-language-turns-two.article:.image go-programming-language-turns-two_costume.jpg
go-slices-usage-and-internals.article:.image go-slices-usage-and-internals_slice-array.png
go-slices-usage-and-internals.article:.image go-slices-usage-and-internals_slice-struct.png
go-version-1-is-released.article:.image go-version-1-is-released_gophermega.jpg
introducing-go-playground.article:.image introducing-go-playground_Untitled.png
osconreport.article:.image osconreport/talks.png _ 800
osconreport.article:.image osconreport/workshops.png _ 800
osconreport.article:.image osconreport/meetup.png _ 800
osconreport.article:.image osconreport/random.png _ 800
playground.article:.image playground/overview.png
profiling-go-programs.article:.image profiling-go-programs_havlak1a-75.png
profiling-go-programs.article:.image profiling-go-programs_havlak1-hash_lookup-75.png

[Andrew Gerrand]

Summary: Go 1.3.2 is broken on Windows.

There have been reports of issues with the 1.3.2 release.

The test failures on Windows are real: Windows users should avoid 1.3.2 and continue to use Go 1.3.1. 

The test failures on other systems are benign and may be ignored.

To resolve these issues, we will issue the 1.3.3 release in the next couple of days.

Apologies for the inconvenience.

Andrew

[Andrew Gerrand]

Thanks for the reports, everyone.

There were definitely some issues with the release.

All the issues reported in this thread will be resolved by a 1.3.3 release in the next couple of days.

[John Tuley]

Is it possible to get https://codereview.appspot.com/136710044/ included in 1.3.3? This is blocking my team from updating some production code past 1.2.2.

Thanks!

– John Tuley

[Andrew Gerrand]

Unfortunately not; the bar for point release fixes is very high.

Can't you just patch your Go tool chain to fix that specific issue?

[John Tuley]

If it were internal code, we would do exactly that. Unfortunately for us, the affected coffee is in an open-source library, and of course we can't rely on other people patching their tool chain.

That being said, I understand your reluctance. We'll make do if we have to.

– John Tuley

[Rob Pike]

Oh dear, if coffee is affected we might have to reconsider.

-rob

[John Tuley]

My apologies for the typo. There is no coffee affected; the issue isn't THAT dire.

– John Tuley

[Brad Fitzpatrick]

I don't understand.

If you can't trust your users to X, why could you trust them to update go Go 1.3.3?

On Mon, Sep 29, 2014 at 6:11 PM, John Tuley <jo...@tuley.org> wrote:

[tomwilde]

X = Patch their Go toolchain.

They want to release code into an open source library that wouldn't work with any Go version >1.2.2.

They rely on their users having a reasonably current Go version (so >1.2.2).

Code cannot be published cause everyone who uses it would need to patch.

That's what I understood.