The X.509 parser was allowing trailing data after a number of structures
in certificates and public keys. There's no obvious security issue here,
esp in certificates which are signed anyway, but this change makes
trailing data an error just in case.

Fixes #10583

Change-Id: Idc289914899600697fc6d30482227ff4bf479241
Reviewed-on: https://go-review.googlesource.com/9473Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>

This is the second in a two-part change. See https://golang.org/cl/9415
for details of the overall change.

This change updates the supported signature algorithms to include
SHA-384 and updates all the testdata/ files accordingly. Even some of
the testdata/ files named “TLS1.0” and “TLS1.1” have been updated
because they have TLS 1.2 ClientHello's even though the server picks a
lower version.

Fixes #9757.

Change-Id: Ia76de2b548d3b39cd4aa3f71132b0da7c917debd
Reviewed-on: https://go-review.googlesource.com/9472Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Prior to TLS 1.2, the handshake had a pleasing property that one could
incrementally hash it and, from that, get the needed hashes for both
the CertificateVerify and Finished messages.

TLS 1.2 introduced negotiation for the signature and hash and it became
possible for the handshake hash to be, say, SHA-384, but for the
CertificateVerify to sign the handshake with SHA-1. The problem is that
one doesn't know in advance which hashes will be needed and thus the
handshake needs to be buffered.

Go ignored this, always kept a single handshake hash, and any signatures
over the handshake had to use that hash.

However, there are a set of servers that inspect the client's offered
signature hash functions and will abort the handshake if one of the
server's certificates is signed with a hash function outside of that
set. https://robertsspaceindustries.com/ is an example of such a server.

Clearly not a lot of thought happened when that server code was written,
but its out there and we have to deal with it.

This change decouples the handshake hash from the CertificateVerify
hash. This lays the groundwork for advertising support for SHA-384 but
doesn't actually make that change in the interests of reviewability.
Updating the advertised hash functions will cause changes in many of the
testdata/ files and some errors might get lost in the noise. This change
only needs to update four testdata/ files: one because a SHA-384-based
handshake is now being signed with SHA-256 and the others because the
TLS 1.2 CertificateRequest message now includes SHA-1.

This change also has the effect of adding support for
client-certificates in SSLv3 servers. However, SSLv3 is now disabled by
default so this should be moot.

It would be possible to avoid much of this change and just support
SHA-384 for the ServerKeyExchange as the SKX only signs over the nonces
and SKX params (a design mistake in TLS). However, that would leave Go
in the odd situation where it advertised support for SHA-384, but would
only use the handshake hash when signing client certificates. I fear
that'll just cause problems in the future.

Much of this code was written by davidben@ for the purposes of testing
BoringSSL.

Partly addresses #9757

Change-Id: I5137a472b6076812af387a5a69fc62c7373cd485
Reviewed-on: https://go-review.googlesource.com/9415
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>

Change-Id: Ie36fd46ad3c0799200fdf4240483a207335570d8
Reviewed-on: https://go-review.googlesource.com/9531Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Change-Id: I6cebaf42f2596c7f8fef3a67afb1e5ccb428d09c
Reviewed-on: https://go-review.googlesource.com/9521Reviewed-by: Ian Lance Taylor <iant@golang.org>

This exercises the linker as well as the compiler.

Credit to Matthew Dempsky; see #10418.

Change-Id: I793947c0c617a34e23df766bff5238ff3ac3c0af
Reviewed-on: https://go-review.googlesource.com/9530Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #8840

Change-Id: I194d0248734c15336f91a6bcf57ffcc9c0a3a435
Reviewed-on: https://go-review.googlesource.com/9434Reviewed-by: David Crawshaw <crawshaw@golang.org>

Just a first basic test, I'll extend this to test more but want to get an
opinion on basic approach first.

Change-Id: Idab9ebd7d9960b000b81a01a1e53258bf4bce755
Reviewed-on: https://go-review.googlesource.com/9386Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>

This change deflakes timeout, deadline tests, especially fixes socket
and goroutine leaks. Also adds a few missing tests that use features
introduced after go1 release.

Change-Id: Ibf73a4859f8d4a0ee494ca2fd180cbce72a7a2c7
Reviewed-on: https://go-review.googlesource.com/9464Reviewed-by: Ian Lance Taylor <iant@golang.org>

Reduces allocations in the compiler by ~1.5%.

No functional changes. Passes toolstash -cmp.

Change-Id: I2416f7fb0aaf9b7d6783c79e840039ad8fa7b5a3
Reviewed-on: https://go-review.googlesource.com/9419Reviewed-by: Russ Cox <rsc@golang.org>

This change merges unicast_posix_test.go and multicast_test.go into
listen_test.go before deflaking tests for Listen functions.

No code changes.

Change-Id: Ic4cd6531b95dfb5b6e6e254241692eca61a71e94
Reviewed-on: https://go-review.googlesource.com/9460Reviewed-by: Ian Lance Taylor <iant@golang.org>

This change adds missing CloseRead test and Close tests on Conn,
Listener and PacketConn with various networks.

Change-Id: Iadf99eaf526a323f853d203edc7c8d0577f67972
Reviewed-on: https://go-review.googlesource.com/9469Reviewed-by: Ian Lance Taylor <iant@golang.org>

Change-Id: I7b15c027c15eefc2a004eb61491e828a7fbefc54
Reviewed-on: https://go-review.googlesource.com/9513Reviewed-by: Russ Cox <rsc@golang.org>

Fixes an issue where Response.Write writes out a Content-Length: -1
header when the corresponding Request is a POST or PUT and the
ContentLength was not previously set.

This was encountered when using httputil.DumpResponse
to write out the response from a server that responded to a PUT
request with no Content-Length header. The dumped output is
thus invalid.

Change-Id: I52c6ae8ef3443f1f9de92aeee9f9581dabb05991
Reviewed-on: https://go-review.googlesource.com/9496Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

Not only by network, transport-layer intermediaries but by
virtualization stuff in a node, it is hard to identify the root cause of
weird faults without information of packet flows after disaster
happened.

This change adds Source field to OpError to be able to represent a
5-tuple of internet transport protocols for helping dealing with
complicated systems.

Also clarifies the usage of Source and Addr fields.

Updates #4856.

Change-Id: I96a523fe391ed14406bfb21604c461d4aac2fa19
Reviewed-on: https://go-review.googlesource.com/9231Reviewed-by: Ian Lance Taylor <iant@golang.org>

Change-Id: I77887d247d3e5d60305fc76f962652268827b955
Reviewed-on: https://go-review.googlesource.com/9516Reviewed-by: David Crawshaw <crawshaw@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: I5569dcdefe8adba346810124b16721674956bce6
Reviewed-on: https://go-review.googlesource.com/9515Reviewed-by: Ian Lance Taylor <iant@golang.org>

RFC 1035 3.3.14 allows a TXT record to contain one or more <character-string>s.
The current implementation returns a "no such host" error if there is more
than one <character-string> in the TXT record.

Fixes #10482

Change-Id: I0ded258005e6b7ba45f687fecd10afa2b321bb77
Reviewed-on: https://go-review.googlesource.com/8966Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>

The TestAfterQueueing test is inherently flaky because it relies on
independent kernel threads being scheduled within the "delta" duration
of each other.  Normally, delta is 100ms but during "short" testing,
it's reduced to 20ms.

On at least OpenBSD, the CPU scheduler operates in 10ms time slices,
so high system load (e.g., from running multiple Go unit tests in
parallel, as happens during all.bash) can occasionally cause >20ms
scheduling delays and result in test flaking.  This manifests as issue
9903, which is the currently the most common OpenBSD flake.

To mitigate this delay, only reduce the delta duration to 20ms for the
first attempt during short testing.  If this fails and the test is
reattempted, subsequent attempts instead use a full 100ms delta.

Fixes #9903.

Change-Id: I11bdfa939e5be915f67ffad8a8aef6ed8772159a
Reviewed-on: https://go-review.googlesource.com/9510
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

For new compile-only builder.

Change-Id: Ic374c582fcada761386fc852fdbdba814b4ac9e2
Reviewed-on: https://go-review.googlesource.com/9438Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>

Update #10305

Change-Id: Iea04758bc200038a1c64457a68100dcdd7f75212
Reviewed-on: https://go-review.googlesource.com/9440Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Sequence of operations:
- Go code does a systemstack call
- during the systemstack call, receive a signal
- signal requests a traceback of all goroutines

The orignal G is still marked as _Grunning, so the traceback code
refuses to print its stack.

Fix by allowing traceback of Gs whose caller is on the same M as G is.
G can't be modifying its stack if that is the case.

Fixes #10546

Change-Id: I2bcea48c0197fbf78ab6fa080027cd80181083ad
Reviewed-on: https://go-review.googlesource.com/9435Reviewed-by: Ian Lance Taylor <iant@golang.org>

The problem is not actually specific to android/arm. Linux/ARM's
runtime.clone set the stack pointer to child_stk-4 before calling
the fn. And then when fn returns, it tries to write to 4(R13) to
provide argument for runtime.exit, which is just beyond the allocated
child stack, and thus it will corrupt the heap randomly or trigger
segfault if that memory happens to be unmapped.

While we're at here, shorten the test polling interval to 0.1s to
speed up the test (it was only checking at 1s interval, which means
the test takes at least 1s).

Fixes #10548.

Change-Id: I57cd63232022b113b6cd61e987b0684ebcce930a
Reviewed-on: https://go-review.googlesource.com/9457Reviewed-by: David Crawshaw <crawshaw@golang.org>

Print it out much like godoc so there isn't a single block of text.
Print the symbol before its comment and indent the comment so
individual symbols separate visually.

Buffer the output.

Add a -c option to force case-sensitive matching.

Allow two arguments, like godoc, to help disambiguate cases
where path and symbol may be confused.

Improve the documentation printed by go help doc.

Change-Id: If687aad04bbacdf7dbe4bf7636de9fe96f756fd0
Reviewed-on: https://go-review.googlesource.com/9471Reviewed-by: Russ Cox <rsc@golang.org>

The heap statistics were only written if asked for a profile with debug > 0,
but that also prints a stack trace for each profile line, which is comparatively
much noisier. The statistics are short enough and separate enough
(they only appear at the end) and useful enough that we can print them
always.

This means that people using -test.memprofile in tests will get a memory
profile with statistics included now. Pprof won't care, but if people care to
look, the numbers will be there.

This avoids the need for hacks like using -memprofilerate=1 to find
the number of allocations.

Change-Id: I10a4f593403d0315aad11b37c6e554b734caa73f
Reviewed-on: https://go-review.googlesource.com/9491Reviewed-by: David Chase <drchase@google.com>

Removes the unused *bufio.Reader from the object controlling the
linker's primary output.

Change-Id: If91d9f60752f3dc4b280f35d6eb441f3c47574b2
Reviewed-on: https://go-review.googlesource.com/9362Reviewed-by: Ian Lance Taylor <iant@golang.org>

This doesn't test much with gccgo, but at least it builds now, and the
test does, unsurprisingly, pass.  A proper test would require adding
assembly files in GCC syntax for all platforms that gccgo supports,
which would be infeasible.

Also added copyright headers to the asm files.

Change-Id: Icea5af29d7d521a0681506ddb617a79705b76d33
Reviewed-on: https://go-review.googlesource.com/9417Reviewed-by: Minux Ma <minux@golang.org>

Disable disassembly with external linking test on openbsd/arm, since this
platform does not currently support cgo/external linking.

Change-Id: I6eab6fcaac21407ce05075a4a1407fbfe0e6142b
Reviewed-on: https://go-review.googlesource.com/9481Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

When reading the object files for linking, liblink takes care of
generate the data for them.

This is a port of https://golang.org/cl/3101 to Go.

Change-Id: Ie3e2d6515bd7d253a8c1e25c70ef8fed064436d8
Signed-off-by: Shenghou Ma <minux@golang.org>
Reviewed-on: https://go-review.googlesource.com/8383Reviewed-by: Ian Lance Taylor <iant@golang.org>

There's no need to call/ret to the body implementation.
It can write the result to the right place.  Just jump to
it and have it return to our caller.

Old:
  call body implementation
  compute result
  put result in a register
  return
  write register to result location
  return

New:
  load address of result location into a register
  jump to body implementation
  compute result
  write result to passed-in address
  return

It's a bit tricky on 386 because there is no free register
with which to pass the result location.  Free up a register
by keeping around blen-alen instead of both alen and blen.

Change-Id: If2cf0682a5bf1cc592bdda7c126ed4eee8944fba
Reviewed-on: https://go-review.googlesource.com/9202Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

Gdb is not able to backtrace our non-standard stack frames on RISC
architectures without frame pointer.

Change-Id: Id62a566ce2d743602ded2da22ff77b9ae34bc5ae
Signed-off-by: Shenghou Ma <minux@golang.org>
Reviewed-on: https://go-review.googlesource.com/9456Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

GIF's bounds.

Also change the implicit Config Width and Height to be the
Rectangle.Max, not the Dx and Dy, of the first frame's bounds. For the
case where the first frame's bounds is something like (5,5)-(8,8), the
overall width should be 8, not 3.

Change-Id: I3affc484f5e32941a36f15517a92ca8d189d9c22
Reviewed-on: https://go-review.googlesource.com/9465Reviewed-by: Rob Pike <r@golang.org>

Also, please be informed that the Write method on both connected and
unconnected-mode sockets may return a positive number of bytes written
with timeout or use of closed network connection error.

Change-Id: I2e2e6192e29cef4e9389eb0422c605c6d12e6a3c
Reviewed-on: https://go-review.googlesource.com/9466Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

This started out as trying to remove Bool2int calls, which it does a bit, but
mostly it ended up being removing the Link.Symmorestack array which seemed a
pointless bit of caching.

Change-Id: I91a51eb08cb4b08f3f9f093b575306499267b67a
Reviewed-on: https://go-review.googlesource.com/9239Reviewed-by: Minux Ma <minux@golang.org>
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

With 128KB stack reservation, on 32-bit Windows, the maximum number
threads is ~9000.

The original 65535-byte stack commit is causing problem on Windows
XP where it makes the stack reservation to be 1MB despite the fact
that the runtime specified 128KB.

While we're at here, also fix the extra spacings in the unable to
create more OS thread error message: println will insert a space
between each argument.

See #9457 for more information.

Change-Id: I3a82f7d9717d3d55211b6eb1c34b00b0eaad83ed
Reviewed-on: https://go-review.googlesource.com/2237Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Minux Ma <minux@golang.org>

In the followup changes, tests that require external facilities such as
DNS servers and RRs will move into external_test.go.

Change-Id: Ib460b0c51961159830357652dbf5430e1ba01514
Reviewed-on: https://go-review.googlesource.com/9461Reviewed-by: Dave Cheney <dave@cheney.net>

They have to read the boolean into a register first and then do
the comparison.

Fixes #10598.

Change-Id: I2b808837a8c6393e1e0778296b6592aaab2b04bf
Signed-off-by: Shenghou Ma <minux@golang.org>
Reviewed-on: https://go-review.googlesource.com/9453Reviewed-by: Dave Cheney <dave@cheney.net>

To avoid confusion with the runtime concept of copying stack.

Change-Id: I33442377b71012c2482c2d0ddd561492c71e70d0
Reviewed-on: https://go-review.googlesource.com/8639Reviewed-by: Dave Cheney <dave@cheney.net>
Reviewed-by: Russ Cox <rsc@golang.org>

The previous CL implemented decoding, but not encoding.

Also return the global color map (if present) for DecodeConfig.

Change-Id: I3b99c93720246010c9fe0924dc40a67875dfc852
Reviewed-on: https://go-review.googlesource.com/9389Reviewed-by: Rob Pike <r@golang.org>

Technically you must initialize static pthread_mutex_t and
pthread_cond_t variables with the appropriate INITIALIZER macro.  In
practice the default initializers are zero anyhow, but it's still good
code hygiene.

Change-Id: I517304b16c2c7943b3880855c1b47a9a506b4bdf
Reviewed-on: https://go-review.googlesource.com/9433Reviewed-by: David Crawshaw <crawshaw@golang.org>