RHEL 7 introduces a new tool, update-ca-trust(8), which places the
certificate bundle in a new location. Add this path to the list of
locations that are searched for the certificate bundle.
Fixes#15749
Change-Id: Idc97f885ee48ef085f1eb4dacbd1c2cf55f94ff5
Reviewed-on: https://go-review.googlesource.com/30375
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Also adds two tests: one to exercise the counter incrementing code
and one which checks the output of the optimized implementation
against that of the generic implementation for large/unaligned data
sizes.
Uses the KIMD instruction for GHASH and the KMCTR instruction for AES
in counter mode.
AESGCMSeal1K 75.0MB/s ± 2% 1008.7MB/s ± 1% +1245.71% (p=0.000 n=10+10)
AESGCMOpen1K 75.3MB/s ± 1% 1006.0MB/s ± 1% +1235.59% (p=0.000 n=10+9)
AESGCMSeal8K 78.5MB/s ± 1% 1748.4MB/s ± 1% +2127.34% (p=0.000 n=9+10)
AESGCMOpen8K 78.5MB/s ± 0% 1752.7MB/s ± 0% +2134.07% (p=0.000 n=10+9)
Change-Id: I88dbcfcb5988104bfd290ae15a60a2721c1338be
Reviewed-on: https://go-review.googlesource.com/30361
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The aim is to make the decrypt() timing profile constant, irrespective of
the CBC padding length or correctness. The old algorithm, on valid padding,
would only MAC bytes up to the padding length threshold, making CBC
ciphersuites vulnerable to plaintext recovery attacks as presented in the
"Lucky Thirteen" paper.
The new algorithm Write()s to the MAC all supposed payload, performs a
constant time Sum()---which required implementing a constant time Sum() in
crypto/sha1, see the "Lucky Microseconds" paper---and then Write()s the rest
of the data. This is performed whether the padding is good or not.
This should have no explicit secret-dependent timings, but it does NOT
attempt to normalize memory accesses to prevent cache timing leaks.
Updates #13385
Change-Id: I15d91dc3cc6eefc1d44f317f72ff8feb0a9888f7
Reviewed-on: https://go-review.googlesource.com/18130
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The code comment mixed up max and min. In this case, min is correct
because this entropy is only used to make the signature scheme
probabilistic. (I.e. if it were fixed then the scheme would still be
secure except that key.Sign(foo) would always give the same result for a
fixed key and foo.)
For this purpose, 256-bits is plenty.
Fixes#16819.
Change-Id: I309bb312b775cf0c4b7463c980ba4b19ad412c36
Reviewed-on: https://go-review.googlesource.com/30153
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Currently, if a certificate contains no names (that we parsed),
verification will return the confusing error:
x509: certificate is valid for , not example.com.
This change improves the error for that situation.
Fixes#16834.
Change-Id: I2ed9ed08298d7d50df758e503bdb55277449bf55
Reviewed-on: https://go-review.googlesource.com/30152
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Since there's no aspect of key logging that OpenSSL can check for us,
the tests for it might as well just connect to another goroutine as this
is lower-maintainance.
Change-Id: I746d1dbad1b4bbfc8ef6ccf136ee4824dbda021e
Reviewed-on: https://go-review.googlesource.com/30089
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Joonas Kuorilehto <joneskoo@derbian.fi>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
readRecord was not returning early if c.in.decrypt failed and ran
through the rest of the function. It does set c.in.err, so the various
checks in the callers do ultimately notice before acting on the result,
but we should avoid running the rest of the function at all.
Also rename 'err' to 'alertValue' since it isn't actually an error.
Change-Id: I6660924716a85af704bd3fe81521b34766238695
Reviewed-on: https://go-review.googlesource.com/24709
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
After renegotiation support was added (af125a5193) it's possible for a
Write to block on a Read when racing to complete the handshake:
1. The Write determines that a handshake is needed and tries to
take the neccesary locks in the correct order.
2. The Read also determines that a handshake is needed and wins
the race to take the locks.
3. The Read goroutine completes the handshake and wins a race
to unlock and relock c.in, which it'll hold when waiting for
more network data.
If the application-level protocol requires the Write to complete before
data can be read then the system as a whole will deadlock.
Unfortunately it doesn't appear possible to reverse the locking order of
c.in and handshakeMutex because we might read a renegotiation request at
any point and need to be able to do a handshake without unlocking.
So this change adds a sync.Cond that indicates that a goroutine has
committed to doing a handshake. Other interested goroutines can wait on
that Cond when needed.
The test for this isn't great. I was able to reproduce the deadlock with
it only when building with -race. (Because -race happened to alter the
timing just enough.)
Fixes#17101.
Change-Id: I4e8757f7b82a84e46c9963a977d089f0fb675495
Reviewed-on: https://go-review.googlesource.com/29164
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
If there are too few primes of the given length then it can be
impossible to generate an RSA key with n distinct primes.
This change approximates the expected number of candidate primes and
causes key generation to return an error if it's unlikely to succeed.
Fixes#16596.
Change-Id: I53b60d0cb90e2d0e6f0662befa64d13f24af51a7
Reviewed-on: https://go-review.googlesource.com/28969
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Since 2a8c81ff handshake messages are not written directly to wire but
buffered. If an error happens at the wrong time the alert will be
written to the buffer but never flushed, causing an EOF on the client
instead of a more descriptive alert.
Thanks to Brendan McMillion for reporting this.
Fixes#17037
Change-Id: Ie093648aa3f754f4bc61c2e98c79962005dd6aa2
Reviewed-on: https://go-review.googlesource.com/28818
Reviewed-by: Adam Langley <agl@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Concurrent use of tls.Config is allowed, and may lead to
KeyLogWriter being written to concurrently. Without a mutex
to protect it, corrupted output may occur. A mutex is added
for correctness.
The mutex is made global to save size of the config struct as
KeyLogWriter is rarely enabled.
Related to #13057.
Change-Id: I5ee55b6d8b43a191ec21f06e2aaae5002a71daef
Reviewed-on: https://go-review.googlesource.com/29016
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The maximum input plaintext for GCM is 64GiB - 64. Since the GCM
interface is one-shot, it's very hard to hit this in Go (one would need
a 64GiB buffer in memory), but we should still enforce this limit.
Thanks to Quan Nguyen for pointing it out.
Change-Id: Icced47bf8d4d5dfbefa165cf13e893205c9577b8
Reviewed-on: https://go-review.googlesource.com/28410
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
In Go 1.0, the Config struct consisted only of exported fields.
In Go 1.1, it started to grow private, uncopyable fields (sync.Once,
sync.Mutex, etc).
Ever since, people have been writing their own private Config.Clone
methods, or risking it and doing a language-level shallow copy and
copying the unexported sync variables.
Clean this up and export the Config.clone method as Config.Clone.
This matches the convention of Template.Clone from text/template and
html/template at least.
Fixes#15771
Updates #16228 (needs update in x/net/http2 before fixed)
Updates #16492 (not sure whether @agl wants to do more)
Change-Id: I48c2825d4fef55a75d2f99640a7079c56fce39ca
Reviewed-on: https://go-review.googlesource.com/28075
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
The goal for these examples is to show how to mirror the
functionality of the sha256sum Unix utility, a common checksumming
tool, using the Go standard library.
Add a newline at the end of the input, so users will get the same
output if they type `echo 'hello world' | sha256sum`, since the
builtin shell echo appends a newline by default. Also use hex output
(instead of the shorter base64) since this is the default output
encoding for shasum/sha256sum.
Change-Id: I0036874b3cc5ba85432bfcb86f81b51c4e0238fd
Reviewed-on: https://go-review.googlesource.com/24868
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Fix bug in UnknownAuthorityError.Error that would never allow Org
Name to be inserted into error message if the Common Name was empty.
Create tests for all three paths in UnknownAuthorityError.Error
Change-Id: Id8afc444e897ef549df682d93a8563fd9de22a2b
Reviewed-on: https://go-review.googlesource.com/27992
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change makes sure that tests are run with the correct
version of the go tool. The correct version is the one that
we invoked with "go test", not the one that is first in our path.
Fixes#16577
Change-Id: If22c8f8c3ec9e7c35d094362873819f2fbb8559b
Reviewed-on: https://go-review.googlesource.com/28089
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The existing implementation used a pure go implementation, leading to slow
cryptographic performance.
Implemented mulWW, subVV, mulAddVWW, addMulVVW, and bitLen for
ppc64{le}.
Implemented divWW for ppc64le only, as the DIVDEU instruction is only
available on Power8 or newer.
benchcmp output:
benchmark old ns/op new ns/op delta
BenchmarkSignP384 28934360 10877330 -62.41%
BenchmarkRSA2048Decrypt 41261033 5139930 -87.54%
BenchmarkRSA2048Sign 45231300 7610985 -83.17%
Benchmark3PrimeRSA2048Decrypt 20487300 2481408 -87.89%
Fixes#16621
Change-Id: If8b68963bb49909bde832f2bda08a3791c4f5b7a
Reviewed-on: https://go-review.googlesource.com/26951
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Munday <munday@ca.ibm.com>
Add support for writing TLS client random and master secret
in NSS key log format.
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format
Normally this is enabled by a developer debugging TLS based
applications, especially HTTP/2, by setting the KeyLogWriter
to an open file. The keys negotiated in handshake are then
logged and can be used to decrypt TLS sessions e.g. in Wireshark.
Applications may choose to add support similar to NSS where this
is enabled by environment variable, but no such mechanism is
built in to Go. Instead each application must explicitly enable.
Fixes#13057.
Change-Id: If6edd2d58999903e8390b1674ba4257ecc747ae1
Reviewed-on: https://go-review.googlesource.com/27434
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Add missing function prototypes.
Fix function prototypes.
Use FP references instead of SP references.
Fix variable names.
Update comments.
Clean up whitespace. (Not for vet.)
All fairly minor fixes to make vet happy.
Updates #11041
Change-Id: Ifab2cdf235ff61cdc226ab1d84b8467b5ac9446c
Reviewed-on: https://go-review.googlesource.com/27713
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Found by vet.
Updates #11041
Change-Id: I5217b3e20c6af435d7500d6bb487b9895efe6605
Reviewed-on: https://go-review.googlesource.com/27493
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In other systems, putting a leaf certificate in the root store works to
express that exactly that certificate is acceptable. This change makes
that work in Go too.
Fixes#16763.
Change-Id: I5c0a8dbc47aa631b23dd49061fb217ed8b0c719c
Reviewed-on: https://go-review.googlesource.com/27393
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
For some reason, ISO decided to duplicate the OID for RSA+SHA1. Most
pertinantly, the makecert.exe utility on Windows is known to have used
this OID.
This change makes the ISO OID an alias for the normal one.
Change-Id: I60b76265bf1721282bdb0d5c99c98d227c18a878
Reviewed-on: https://go-review.googlesource.com/27394
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
If SetSessionTicketKeys was called on a fresh tls.Config, the configured
keys would be overridden with a random key by serverInit.
Fixes#15421.
Change-Id: I5d6cc81fc3e5de4dfa15eb614d102fb886150d1b
Reviewed-on: https://go-review.googlesource.com/27317
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
These were new with TLS 1.2 and, reportedly, some servers require it.
Since it's easy, this change adds suport for three flavours of
AES-128-CBC with SHA-256 MACs.
Other testdata/ files have to be updated because this changes the list
of cipher suites offered by default by the client.
Fixes#15487.
Change-Id: I1b14330c31eeda20185409a37072343552c3464f
Reviewed-on: https://go-review.googlesource.com/27315
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Jonathan Rudenberg <jonathan@titanous.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Although the term “RSA” is almost synonymous with PKCS#1 v1.5, that
standard is quite flawed, cryptographically speaking. Bellare and
Rogaway fixed PKCS#1 v1.5 with OAEP (for encryption) and PSS (for
signatures) but they only see a fraction of the use of v1.5.
This change adds support for creating and verifying X.509 certificates
that use PSS signatures. Sadly, every possible dimension of flexibility
seems to have been reflected in the integration of X.509 and PSS
resulting in a huge amount of excess complexity. This change only
supports one “sane” configuration for each of SHA-{256, 384, 512}.
Hopefully this is sufficient because it saves a lot of complexity in the
code.
Although X.509 certificates with PSS signatures are rare, I'm inclined
to look favourably on them because they are sufficiently superior.
Fixes#15958.
Change-Id: I7282e0b68ad0177209f8b2add473b94aa5224c07
Reviewed-on: https://go-review.googlesource.com/24743
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The RFC is clear that the Parameters in an AlgorithmIdentifer for an RSA
public key must be NULL. BoringSSL enforces this so we have strong
evidence that this is a widely compatible change.
Embarrassingly enough, the major source of violations of this is us. Go
used to get this correct in only one of two places. This was only fixed
in 2013 (with 4874bc9b). That's why lots of test certificates are
updated in this change.
Fixes#16166.
Change-Id: Ib9a4551349354c66e730d44eb8cee4ec402ea8ab
Reviewed-on: https://go-review.googlesource.com/27312
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
subtle.ConstantTimeCompare now tests the length of the inputs (although
it didn't when this code was written) so this test in crypto/hmac is now
superfluous.
Fixes#16336.
Change-Id: Ic02d8537e776fa1dd5694d3af07a28c4d840d14b
Reviewed-on: https://go-review.googlesource.com/27239
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
If the SerialNumber is nil in the template then the resulting panic is
rather deep in encoding/asn1 and it's not obvious what went wrong.
This change tests and returns a more helpful error in this case.
Fixes#16603.
Change-Id: Ib30d652555191eb78f705dff8d909e4b5808f9ca
Reviewed-on: https://go-review.googlesource.com/27238
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Moves the state.ServerName assignment to outside the if
statement that checks for handshakeComplete.
Fixes#15571
Change-Id: I6c4131ddb16389aed1c410a975f9aa3b52816965
Reviewed-on: https://go-review.googlesource.com/22862
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
Give *recordingConn the correct WriteTo signature
to be an io.WriterTo. This makes vet happy.
It also means that it'll report errors,
which were previously being ignored.
Updates #11041
Change-Id: I13f171407d63f4b62427679bff362eb74faddca5
Reviewed-on: https://go-review.googlesource.com/27121
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
VPSHUFD should take an unsigned argument to be consistent with
PSHUFD. Also fix all usage.
Fixes#16499
Change-Id: Ie699c102afed0379445914a251710365b14d89b6
Reviewed-on: https://go-review.googlesource.com/25383
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
https://golang.org/cl/25233 was detecting the OS X release at compile
time, not run time. Detect it at run time instead.
Fixes#16473 (again)
Change-Id: I6bec4996e57aa50c52599c165aa6f1fae7423fa7
Reviewed-on: https://go-review.googlesource.com/25281
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Chris Broadfoot <cbro@golang.org>
Conservative fix for the OS X 10.8 crash. We can unify them back together
during the Go 1.8 dev cycle.
Fixes#16473
Change-Id: If07228deb2be36093dd324b3b3bcb31c23a95035
Reviewed-on: https://go-review.googlesource.com/25233
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
I believe it's necessary to use a buffer size smaller than 64KB because
(at least some versions of) Window using a TCP receive window less than
64KB. Currently the client and server use buffer sizes of 16KB and 32KB,
respectively (the server uses io.Copy, which defaults to 32KB internally).
Since the server has been using 32KB, it should be safe for the client to
do so as well.
Fixes#15899
Change-Id: I36d44b29f2a5022c03fc086213d3c1adf153e983
Reviewed-on: https://go-review.googlesource.com/24581
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This fixes some 40 warnings from go vet.
Fixes#16134.
Change-Id: Ib9fcba275fe692f027a2a07b581c8cf503b11087
Reviewed-on: https://go-review.googlesource.com/24287
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
I don't see how the call could fail, so, no test. Just a code cleanup in
case it can fail in the future.
Fixes#15987.
Change-Id: If4af0d5e7d19cc8b13fb6a4f7661c37fb0015e83
Reviewed-on: https://go-review.googlesource.com/23860
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
Change-Id: I68d66fccf9cc8f7137c92b94820ce7d6f478a185
Reviewed-on: https://go-review.googlesource.com/23310
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This change causes TLS handshake messages to be buffered and written in
a single Write to the underlying net.Conn.
There are two reasons to want to do this:
Firstly, it's slightly preferable to do this in order to save sending
several, small packets over the network where a single one will do.
Secondly, since 37c28759ca errors from
Write have been returned from a handshake. This means that, if a peer
closes the connection during a handshake, a “broken pipe” error may
result from tls.Conn.Handshake(). This can mask any, more detailed,
fatal alerts that the peer may have sent because a read will never
happen.
Buffering handshake messages means that the peer will not receive, and
possibly reject, any of a flow while it's still being written.
Fixes#15709
Change-Id: I38dcff1abecc06e52b2de647ea98713ce0fb9a21
Reviewed-on: https://go-review.googlesource.com/23609
Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Andrew Gerrand <adg@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This fixes `go test go/types`.
https://golang.org/cl/23487/ introduced this code which contains
two unused variables (declared and assigned to, but never read).
cmd/compile doesn't report the error due open issue #8560 (the
variables are assigned to in a closure), but go/types does. The
build bot only runs go/types tests in -short mode (which doesn't
typecheck the std lib), hence this doesn't show up on the dashboard
either.
We cannot call b.Fatal and friends in the goroutine. Communicating
the error to the invoking function requires a channel or a mutex.
Unless the channel/sycnhronized variable is tested in each iteration
that follows, the iteration blocks if there's a failure. Testing in
each iteration may affect benchmark times.
One could use a time-out but that time depends on the underlying system.
Panicking seems good enough in this unlikely case; better than hanging
or affecting benchmark times.
Change-Id: Idce1172da8058e580fa3b3e398825b0eb4316325
Reviewed-on: https://go-review.googlesource.com/23528
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The Windows builders run the throughput benchmarks really slowly with a
64kb buffer. Lowering it to 16kb brings the performance back into line
with the other builders.
This is a work-around to get the build green until we can figure out why
the Windows builders are slow with the larger buffer size.
Update #15899
Change-Id: I215ebf115e8295295c87f3b3e22a4ef1f9e77f81
Reviewed-on: https://go-review.googlesource.com/23574
Reviewed-by: Ian Lance Taylor <iant@golang.org>
