Two security-related issues were recently reported, and to address these issues
we have just released Go 1.6.1 and Go 1.5.4.
We recommend that all users update to one of these releases (if you're not sure
which, choose Go 1.6.1).
The issues addressed by these releases are:
On Windows, Go loads system DLLs by name with LoadLibrary, making it vulnerable
to DLL preloading attacks. For instance, if a user runs a Go executable from a
Downloads folder, malicious DLL files also downloaded to that folder could be
loaded into that executable.
This is CVE-2016-3958 and was addressed by this change: https://golang.org/cl/21428
Thanks to Taru Karttunen for identifying this issue.
Go's crypto libraries passed certain parameters unchecked to the underlying big
integer library, possibly leading to extremely long-running computations, which
in turn makes Go programs vulnerable to remote denial of service attacks.
Programs using HTTPS client certificates or the Go SSH server libraries are
both exposed to this vulnerability.
This is CVE-2016-3959 and was addressed by this change: https://golang.org/cl/21533
Thanks to David Wong for identifying this issue.
The latest Go release, version 1.6, arrives six months after 1.5. Most of its
changes are in the implementation of the language, runtime, and libraries.
There are no changes to the language specification. As always, the release
maintains the Go 1 promise of compatibility. We expect almost all Go programs
to continue to compile and run as before.
The release adds new ports to Linux on 64-bit MIPS and Android on 32-bit x86;
defined and enforced rules for sharing Go pointers with C; transparent,
automatic support for HTTP/2; and a new mechanism for template reuse.
Full changelog at https://golang.org/doc/go1.6.
Int.Exp Montgomery code", to fix CVE-2015-8618.
From the oss-security posting that asked for a CVE:
"The Go open source project has received notification of an error in the
math/big library (https://golang.org/pkg/math/big/). The problem that was
identified is similar to CVE-2015-3193
<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3193>. The
vulnerability was introduced in the 1.5 release, and remains present in Go
1.5.1 and 1.5.2.
"A fix for the issue has been applied to the master branch of the Go repo
under CL 17672 <https://go-review.googlesource.com/#/c/17672/>. We will
also be releasing Go 1.5.3 to fix this vulnerability."
ok wiz@
go1.5.2 (released 2015/12/02) includes bug fixes to the compiler,
linker, and the mime/multipart, net, and runtime packages. See the Go
1.5.2 milestone on our issue tracker for details.
https://github.com/golang/go/issues?q=milestone%3AGo1.5.2
go1.5.1 (released 2015/09/08) includes bug fixes to the compiler, assembler,
and the fmt, net/textproto, net/http, and runtime packages. See the Go 1.5.1
milestone on our issue tracker for details:
https://github.com/golang/go/issues?q=milestone%3AGo1.5.1
This release now needs the previous one (lang/go14) to build.
The biggest developments in the implementation are:
* The compiler and runtime are now written entirely in Go (with a little
assembler). C is no longer involved in the implementation, and so the
C compiler that was once necessary for building the distribution is
gone.
* The garbage collector is now concurrent and provides dramatically
lower pause times by running, when possible, in parallel with other
goroutines.
* By default, Go programs run with GOMAXPROCS set to the number of cores
available; in prior releases it defaulted to 1.
* Support for internal packages is now provided for all repositories,
not just the Go core.
* The go command now provides experimental support for "vendoring"
external dependencies.
* A new go tool trace command supports fine-grained tracing of program
execution.
* A new go doc command (distinct from godoc) is customized for
command-line use.
Full release notes are at https://golang.org/doc/go1.5.
Today we announce Go 1.4, the fifth major stable release of Go,
arriving six months after our previous major release Go 1.3. It
contains a small language change, support for more operating systems
and processor architectures, and improvements to the tool chain
and libraries. As always, Go 1.4 keeps the promise of compatibility,
and almost everything will continue to compile and run without
change when moved to 1.4. For the full details, see the Go 1.4
release notes.
The most notable new feature in this release is official support
for Android. Using the support in the core and the libraries in
the golang.org/x/mobile repository, it is now possible to write
simple Android apps using only Go code. At this stage, the support
libraries are still nascent and under heavy development. Early
adopters should expect a bumpy ride, but we welcome the community
to get involved.
The language change is a tweak to the syntax of for-range loops.
You may now write "for range s {" to loop over each item from s,
without having to assign the value, loop index, or map key. See
the release notes for details.
The go command has a new subcommand, go generate, to automate the
running of tools to generate source code before compilation. For
example, it can be used to automate the generation of String methods
for typed constants using the new stringer tool. For more information,
see the design document.
Most programs will run about the same speed or slightly faster in
1.4 than in 1.3; some will be slightly slower. There are many
changes, making it hard to be precise about what to expect. See
the release notes for more discussion.
And, of course, there are many more improvements and bug fixes.
In case you missed it, a few weeks ago the sub-repositories were
moved to new locations. For example, the go.tools packages are now
imported from "golang.org/x/tools". See the announcement post for
details.
This release also coincides with the project's move from Mercurial
to Git (for source control), Rietveld to Gerrit (for code review),
and Google Code to Github (for issue tracking and wiki). The move
affects the core Go repository and its sub-repositories. You can
find the canonical Git repositories at go.googlesource.com, and
the issue tracker and wiki at the golang/go GitHub repo.
Fixes "go get code.google.com/p/..." for me, once security/mozilla-rootcerts
installed and configured (with the default settings).
Bumps PKGREVISION, since the package is modified.
ok bsiegert@
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.
It contains the following fixes:
* runtime: fix crash in runtime.GoroutineProfile
* runtime: if traceback sees a breakpoint, don't change the PC
* runtime: fix data race in GC
* net: ignore some errors in windows Accept
* database/sql: Use all connections in pool
go1.1.2 (released 2013/08/13) includes fixes to the gc compiler and cgo,
and the bufio, runtime, syscall, and time packages. See the change
history for details. If you use package syscall's Getrlimit and
Setrlimit functions under Linux on the ARM or 386 architectures, please
note change 55ac276af5a7 that fixes issue 5949.
This is a leaf package, so it should be ok during the freeze.
The Go programming language is an open source project to make
programmers more productive.
Go is expressive, concise, clean, and efficient. Its concurrency
mechanisms make it easy to write programs that get the most out of
multicore and networked machines, while its novel type system enables
flexible and modular program construction. Go compiles quickly to
machine code yet has the convenience of garbage collection and the power
of run-time reflection. It's a fast, statically typed, compiled language
that feels like a dynamically typed, interpreted language.
