- 01 May, 2015 8 commits
-
-
Shenghou Ma authored
Fixes #10554. Fixes #10623. Change-Id: I90fbaa34e3d55c8758178f8d2e7fa41ff1194a1b Signed-off-by: Shenghou Ma <minux@golang.org> Reviewed-on: https://go-review.googlesource.com/9247Reviewed-by: Dmitry Vyukov <dvyukov@google.com> Reviewed-by: Dave Cheney <dave@cheney.net>
-
Dave Cheney authored
Fix the various builds which don't have a real filesystem or don't support forking. Change-Id: I3075c662fe6191ecbe70ba359b73d9a88bb06f35 Reviewed-on: https://go-review.googlesource.com/9528Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Dave Cheney <dave@cheney.net>
-
Rob Pike authored
Forgot to update the references to the old cover package. No excuse. Change-Id: If17b7521f0bf70bc0c8da9c5adf246d90f644637 Reviewed-on: https://go-review.googlesource.com/9564Reviewed-by: Rob Pike <r@golang.org>
-
Rob Pike authored
TBR=rsc Change-Id: I6ec69013027213c5e7adedd2edb89dea6af876d9 Reviewed-on: https://go-review.googlesource.com/9563Reviewed-by: Rob Pike <r@golang.org>
-
Dave Cheney authored
Fixes #10592 Calling gc.Fatal before gc.Main has been called ends up flushing gc.bstdout before it is properly set up. Ideally obj.Bflush would handle this case, but that type and its callers are rather convoluted, so take the simpler route and avoid calling gc.Fatal altogether. Change-Id: I338b469e86edba558b6bedff35bb904bfc3d6990 Reviewed-on: https://go-review.googlesource.com/9525Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Dave Cheney <dave@cheney.net> Run-TryBot: Dave Cheney <dave@cheney.net> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Rob Pike authored
This was disallowed for error-checking reasons but people ask for it, it's easy, and it's clear what it all means. Fixes #7323. Change-Id: I26542f5ac6519e45b335ad789713a4d9e356279b Reviewed-on: https://go-review.googlesource.com/9537Reviewed-by: Russ Cox <rsc@golang.org>
-
Rob Pike authored
Change-Id: Ie4b59d72e2b704559e075494e79fdc7b0bca6556 Reviewed-on: https://go-review.googlesource.com/9562Reviewed-by: Rob Pike <r@golang.org>
-
Rob Pike authored
This required dealing with the ill-advised split of the profile code into a separate package. I just copied it over unchanged. The package does not deserve to be in the standard repository. We can cope with the duplication. Also update the go command to know about the new location. Fixes #10528. Change-Id: I05170ef3663326d57b9c18888d01163acd9256b6 Reviewed-on: https://go-review.googlesource.com/9560Reviewed-by: Russ Cox <rsc@golang.org>
-
- 30 Apr, 2015 22 commits
-
-
Matthew Dempsky authored
Package time already has enough inherently flaky tests covering its behavior. No need for more of them. Fixes #10632. Change-Id: I1229e9fcc2e28ba2c9b0b79f73638e35dbbe8bbf Reviewed-on: https://go-review.googlesource.com/9517Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
-
Ian Lance Taylor authored
Change-Id: I4cdfd5a59e0468e9e5400aa06334b21cc80913cd Reviewed-on: https://go-review.googlesource.com/9550Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Brad Fitzpatrick authored
Fixes #9876 Change-Id: I97a354fde827dfccc9e373fadea2e37d094439b0 Reviewed-on: https://go-review.googlesource.com/9538Reviewed-by: Rob Pike <r@golang.org>
-
Alex A Skinner authored
Per resolv.conf man page, "If this file does not exist, only the name server on the local machine will be queried." This behavior also occurs if file is present but unreadable, or if no nameservers are listed. Fixes #10566 Change-Id: Id5716da0eae534d5ebfafea111bbc657f302e307 Reviewed-on: https://go-review.googlesource.com/9380 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Michael Hudson-Doyle authored
Change-Id: I611f7dec2109dc7e2f090ced0a1dca3d4b577134 Reviewed-on: https://go-review.googlesource.com/9520Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org>
-
Dave Cheney authored
Fix several warnings generated on the linux-amd64-clang builder and make it clear to clang that -znow is a linker only flag. Tested with env CC=clang-3.5 ./all.bash env CC=gcc-4.8 ./all.bash Change-Id: I5ca7366ba8bf6221a36d25a2157dda4b4f3e16fa Reviewed-on: https://go-review.googlesource.com/9523Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Ian Lance Taylor authored
This extends the cgo changes in http://golang.org/cl/8094 to gccgo. It also adds support for setting runtime_iscgo correctly for gccgo; the gc runtime bases the variable on the runtime/cgo package, but gccgo has no equivalent to that package. The go tool supports -buildmode=c-archive for gccgo by linking all the Go objects together using -r. For convenience this object is then put into an archive file. The go tool now passes -fsplit-stack when building C code for gccgo on 386 and amd64. This is required for using -r and will also cut down on unnecessary stack splits. The go tool no longer applies standard package cgo LDFLAGS when using gccgo. This is mainly to avoid getting confused by the LDFLAGS in the runtime/cgo package that gccgo does not use. Change-Id: I1d0865b2a362818a033ca9e9e901d0ce250784e7 Reviewed-on: https://go-review.googlesource.com/9511Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Didier Spezia authored
The current implementation of the tSpecialTagEnd function is inefficient since it generates plenty of memory allocations and converts the whole buffer to lowercase at each call. If the number of special tags increases linearly with the template size, the complexity becomes quadratic. This CL provides an alternative implementation. While the algorithm is probably still not optimal, it avoids the quadratic behavior and the memory allocations. benchmark old ns/op new ns/op delta BenchmarkTemplateSpecialTags-4 19326431 532190 -97.25% benchmark old allocs new allocs delta BenchmarkTemplateSpecialTags-4 2650 190 -92.83% benchmark old bytes new bytes delta BenchmarkTemplateSpecialTags-4 4106460 46568 -98.87% While we are there, make sure we respect the HTML tokenization algorithm. An end tag needs to be followed by a space, tab, CR, FF, /, or > as described in https://html.spec.whatwg.org/multipage/syntax.html#tokenization Explicitly add this check. Fixes #10605 Change-Id: Ia33ddee164ab608a69ac4183e16ec506bbeaa54c Reviewed-on: https://go-review.googlesource.com/9502Reviewed-by: Rob Pike <r@golang.org>
-
Russ Cox authored
Schedule the work as early as possible, while still respecting the utilization percentage on average. The old code tried never to go above the utilization percentage. The new code is willing to go above the utilization percentage by one time slice (but of course after doing that it must wait until the percentage drops back down to the target before it gets another time slice). The effect is that for concurrent GCs that can run in a small number of time slices, the time during which write barriers are enabled is reduced by one mutator + GC time slice round (possibly 30 ms per GC). This only affects the fractional GC processor (the remainder of GOMAXPROCS/4), so it matters most in GOMAXPROCS=1, a bit in GOMAXPROCS=2, and not at all in GOMAXPROCS=4. GOMAXPROCS=1 name old mean new mean delta BenchmarkBinaryTree17 12.4s × (0.98,1.03) 13.5s × (0.97,1.04) +8.84% (p=0.000) BenchmarkFannkuch11 4.38s × (1.00,1.01) 4.38s × (1.00,1.01) ~ (p=0.343) BenchmarkFmtFprintfEmpty 88.9ns × (0.97,1.10) 90.1ns × (0.93,1.14) ~ (p=0.224) BenchmarkFmtFprintfString 356ns × (0.94,1.05) 321ns × (0.94,1.12) -9.77% (p=0.000) BenchmarkFmtFprintfInt 344ns × (0.98,1.03) 325ns × (0.96,1.03) -5.46% (p=0.000) BenchmarkFmtFprintfIntInt 622ns × (0.97,1.03) 571ns × (0.95,1.05) -8.09% (p=0.000) BenchmarkFmtFprintfPrefixedInt 462ns × (0.96,1.04) 431ns × (0.95,1.05) -6.81% (p=0.000) BenchmarkFmtFprintfFloat 653ns × (0.98,1.03) 621ns × (0.99,1.03) -4.90% (p=0.000) BenchmarkFmtManyArgs 2.32µs × (0.97,1.03) 2.19µs × (0.98,1.02) -5.43% (p=0.000) BenchmarkGobDecode 27.0ms × (0.96,1.04) 20.0ms × (0.97,1.04) -26.06% (p=0.000) BenchmarkGobEncode 26.6ms × (0.99,1.01) 17.8ms × (0.95,1.05) -33.19% (p=0.000) BenchmarkGzip 659ms × (0.98,1.03) 650ms × (0.99,1.01) -1.34% (p=0.000) BenchmarkGunzip 145ms × (0.98,1.04) 143ms × (1.00,1.01) -1.47% (p=0.000) BenchmarkHTTPClientServer 111µs × (0.97,1.04) 110µs × (0.96,1.03) -1.30% (p=0.000) BenchmarkJSONEncode 52.0ms × (0.97,1.03) 40.8ms × (0.97,1.03) -21.47% (p=0.000) BenchmarkJSONDecode 127ms × (0.98,1.04) 120ms × (0.98,1.02) -5.55% (p=0.000) BenchmarkMandelbrot200 6.04ms × (0.99,1.04) 6.02ms × (1.00,1.01) ~ (p=0.176) BenchmarkGoParse 8.62ms × (0.96,1.08) 8.55ms × (0.93,1.09) ~ (p=0.302) BenchmarkRegexpMatchEasy0_32 164ns × (0.98,1.05) 165ns × (0.98,1.07) ~ (p=0.293) BenchmarkRegexpMatchEasy0_1K 546ns × (0.98,1.06) 547ns × (0.97,1.07) ~ (p=0.741) BenchmarkRegexpMatchEasy1_32 142ns × (0.97,1.09) 141ns × (0.97,1.05) ~ (p=0.231) BenchmarkRegexpMatchEasy1_1K 904ns × (0.97,1.07) 900ns × (0.98,1.04) ~ (p=0.294) BenchmarkRegexpMatchMedium_32 256ns × (0.98,1.06) 256ns × (0.97,1.04) ~ (p=0.530) BenchmarkRegexpMatchMedium_1K 74.2µs × (0.98,1.05) 73.8µs × (0.98,1.04) ~ (p=0.334) BenchmarkRegexpMatchHard_32 3.94µs × (0.98,1.07) 3.92µs × (0.98,1.05) ~ (p=0.356) BenchmarkRegexpMatchHard_1K 119µs × (0.98,1.07) 119µs × (0.98,1.06) ~ (p=0.467) BenchmarkRevcomp 978ms × (0.96,1.09) 984ms × (0.95,1.07) ~ (p=0.448) BenchmarkTemplate 151ms × (0.96,1.03) 142ms × (0.95,1.04) -5.55% (p=0.000) BenchmarkTimeParse 628ns × (0.99,1.01) 628ns × (0.99,1.01) ~ (p=0.855) BenchmarkTimeFormat 729ns × (0.98,1.06) 734ns × (0.97,1.05) ~ (p=0.149) GOMAXPROCS=2 name old mean new mean delta BenchmarkBinaryTree17-2 9.80s × (0.97,1.03) 9.85s × (0.99,1.02) ~ (p=0.444) BenchmarkFannkuch11-2 4.35s × (0.99,1.01) 4.40s × (0.98,1.05) ~ (p=0.099) BenchmarkFmtFprintfEmpty-2 86.7ns × (0.97,1.05) 85.9ns × (0.98,1.04) ~ (p=0.409) BenchmarkFmtFprintfString-2 297ns × (0.98,1.01) 297ns × (0.99,1.01) ~ (p=0.743) BenchmarkFmtFprintfInt-2 309ns × (0.98,1.02) 310ns × (0.99,1.01) ~ (p=0.464) BenchmarkFmtFprintfIntInt-2 525ns × (0.97,1.05) 518ns × (0.99,1.01) ~ (p=0.151) BenchmarkFmtFprintfPrefixedInt-2 408ns × (0.98,1.02) 408ns × (0.98,1.03) ~ (p=0.797) BenchmarkFmtFprintfFloat-2 603ns × (0.99,1.01) 604ns × (0.98,1.02) ~ (p=0.588) BenchmarkFmtManyArgs-2 2.07µs × (0.98,1.02) 2.05µs × (0.99,1.01) ~ (p=0.091) BenchmarkGobDecode-2 19.1ms × (0.97,1.01) 19.3ms × (0.97,1.04) ~ (p=0.195) BenchmarkGobEncode-2 16.2ms × (0.97,1.03) 16.4ms × (0.99,1.01) ~ (p=0.069) BenchmarkGzip-2 652ms × (0.99,1.01) 651ms × (0.99,1.01) ~ (p=0.705) BenchmarkGunzip-2 143ms × (1.00,1.01) 143ms × (1.00,1.00) ~ (p=0.665) BenchmarkHTTPClientServer-2 149µs × (0.92,1.11) 149µs × (0.91,1.08) ~ (p=0.862) BenchmarkJSONEncode-2 34.6ms × (0.98,1.02) 37.2ms × (0.99,1.01) +7.56% (p=0.000) BenchmarkJSONDecode-2 117ms × (0.99,1.01) 117ms × (0.99,1.01) ~ (p=0.858) BenchmarkMandelbrot200-2 6.10ms × (0.99,1.03) 6.03ms × (1.00,1.00) ~ (p=0.083) BenchmarkGoParse-2 8.25ms × (0.98,1.01) 8.21ms × (0.99,1.02) ~ (p=0.307) BenchmarkRegexpMatchEasy0_32-2 162ns × (0.99,1.02) 162ns × (0.99,1.01) ~ (p=0.857) BenchmarkRegexpMatchEasy0_1K-2 541ns × (0.99,1.01) 540ns × (1.00,1.00) ~ (p=0.530) BenchmarkRegexpMatchEasy1_32-2 138ns × (1.00,1.00) 141ns × (0.98,1.04) +1.88% (p=0.038) BenchmarkRegexpMatchEasy1_1K-2 887ns × (0.99,1.01) 894ns × (0.99,1.01) ~ (p=0.087) BenchmarkRegexpMatchMedium_32-2 252ns × (0.99,1.01) 252ns × (0.99,1.01) ~ (p=0.954) BenchmarkRegexpMatchMedium_1K-2 73.4µs × (0.99,1.02) 72.8µs × (1.00,1.01) -0.87% (p=0.029) BenchmarkRegexpMatchHard_32-2 3.95µs × (0.97,1.05) 3.87µs × (1.00,1.01) -2.11% (p=0.035) BenchmarkRegexpMatchHard_1K-2 117µs × (0.99,1.01) 117µs × (0.99,1.01) ~ (p=0.669) BenchmarkRevcomp-2 980ms × (0.95,1.03) 993ms × (0.94,1.09) ~ (p=0.527) BenchmarkTemplate-2 136ms × (0.98,1.01) 135ms × (0.99,1.01) ~ (p=0.200) BenchmarkTimeParse-2 630ns × (1.00,1.01) 630ns × (1.00,1.00) ~ (p=0.634) BenchmarkTimeFormat-2 705ns × (0.99,1.01) 710ns × (0.98,1.02) ~ (p=0.174) GOMAXPROCS=4 BenchmarkBinaryTree17-4 9.87s × (0.96,1.04) 9.75s × (0.96,1.03) ~ (p=0.178) BenchmarkFannkuch11-4 4.35s × (1.00,1.01) 4.40s × (0.99,1.04) ~ (p=0.071) BenchmarkFmtFprintfEmpty-4 85.8ns × (0.98,1.06) 85.6ns × (0.98,1.04) ~ (p=0.858) BenchmarkFmtFprintfString-4 306ns × (0.99,1.03) 304ns × (0.97,1.02) ~ (p=0.470) BenchmarkFmtFprintfInt-4 317ns × (0.98,1.01) 315ns × (0.98,1.02) -0.92% (p=0.044) BenchmarkFmtFprintfIntInt-4 527ns × (0.99,1.01) 525ns × (0.98,1.01) ~ (p=0.164) BenchmarkFmtFprintfPrefixedInt-4 421ns × (0.98,1.03) 417ns × (0.99,1.02) ~ (p=0.092) BenchmarkFmtFprintfFloat-4 623ns × (0.98,1.02) 618ns × (0.98,1.03) ~ (p=0.172) BenchmarkFmtManyArgs-4 2.09µs × (0.98,1.02) 2.09µs × (0.98,1.02) ~ (p=0.679) BenchmarkGobDecode-4 18.6ms × (0.99,1.01) 18.6ms × (0.98,1.03) ~ (p=0.595) BenchmarkGobEncode-4 15.0ms × (0.98,1.02) 15.1ms × (0.99,1.01) ~ (p=0.301) BenchmarkGzip-4 659ms × (0.98,1.04) 660ms × (0.97,1.02) ~ (p=0.724) BenchmarkGunzip-4 145ms × (0.98,1.04) 144ms × (0.99,1.04) ~ (p=0.671) BenchmarkHTTPClientServer-4 139µs × (0.97,1.02) 138µs × (0.99,1.02) ~ (p=0.392) BenchmarkJSONEncode-4 35.0ms × (0.99,1.02) 35.1ms × (0.98,1.02) ~ (p=0.777) BenchmarkJSONDecode-4 119ms × (0.98,1.01) 118ms × (0.98,1.02) ~ (p=0.710) BenchmarkMandelbrot200-4 6.02ms × (1.00,1.00) 6.02ms × (1.00,1.00) ~ (p=0.289) BenchmarkGoParse-4 7.96ms × (0.99,1.01) 7.96ms × (0.99,1.01) ~ (p=0.884) BenchmarkRegexpMatchEasy0_32-4 164ns × (0.98,1.04) 166ns × (0.97,1.04) ~ (p=0.221) BenchmarkRegexpMatchEasy0_1K-4 540ns × (0.99,1.01) 552ns × (0.97,1.04) +2.10% (p=0.018) BenchmarkRegexpMatchEasy1_32-4 140ns × (0.99,1.04) 142ns × (0.97,1.04) ~ (p=0.226) BenchmarkRegexpMatchEasy1_1K-4 896ns × (0.99,1.03) 907ns × (0.97,1.04) ~ (p=0.155) BenchmarkRegexpMatchMedium_32-4 255ns × (0.99,1.04) 255ns × (0.98,1.04) ~ (p=0.904) BenchmarkRegexpMatchMedium_1K-4 73.4µs × (0.99,1.04) 73.8µs × (0.98,1.04) ~ (p=0.560) BenchmarkRegexpMatchHard_32-4 3.93µs × (0.98,1.04) 3.95µs × (0.98,1.04) ~ (p=0.571) BenchmarkRegexpMatchHard_1K-4 117µs × (1.00,1.01) 119µs × (0.98,1.04) +1.48% (p=0.048) BenchmarkRevcomp-4 990ms × (0.94,1.08) 989ms × (0.94,1.10) ~ (p=0.957) BenchmarkTemplate-4 137ms × (0.98,1.02) 137ms × (0.99,1.01) ~ (p=0.996) BenchmarkTimeParse-4 629ns × (1.00,1.00) 629ns × (0.99,1.01) ~ (p=0.924) BenchmarkTimeFormat-4 710ns × (0.99,1.01) 716ns × (0.98,1.02) +0.84% (p=0.033) Change-Id: I43a04e0f6ad5e3ba9847dddf12e13222561f9cf4 Reviewed-on: https://go-review.googlesource.com/9543Reviewed-by: Austin Clements <austin@google.com>
-
Josh Bleecher Snyder authored
Change-Id: I187e97592cd0403d84ca25c4acb1a4b25495041b Reviewed-on: https://go-review.googlesource.com/9534Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
-
Austin Clements authored
gcDumpObject is used to print the source and destination objects when checkmark find a missing mark. However, gcDumpObject currently assumes the given pointer will point to a heap object. This is not true of the source object during root marking and may not even be true of the destination object in the limited situations where the heap points back in to the stack. If the pointer isn't a heap object, gcDumpObject will attempt an out-of-bounds access to h_spans. This will cause a panicslice, which will attempt to construct a useful panic message. This will cause a string allocation, which will lead mallocgc to panic because the GC is in mark termination (checkmark only happens during mark termination). Fix this by checking that the pointer points into the heap arena before attempting to use it as an arena pointer. Change-Id: I09da600c380d4773f1f8f38e45b82cb229ea6382 Reviewed-on: https://go-review.googlesource.com/9498Reviewed-by: Rick Hudson <rlh@golang.org>
-
Dmitry Vyukov authored
Change-Id: I1add1b92f5c2688a99133d90bf9789d770fd9f05 Reviewed-on: https://go-review.googlesource.com/9503Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Dmitry Vyukov authored
Change-Id: I05cfacd746e87011de8b659ab3b2fbe23146a7f3 Reviewed-on: https://go-review.googlesource.com/9504Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
-
Dmitry Vyukov authored
Currently the packages have the following index functions: func Index(s, sep []byte) int func IndexAny(s []byte, chars string) int func IndexByte(s []byte, c byte) int func IndexFunc(s []byte, f func(r rune) bool) int func IndexRune(s []byte, r rune) int func LastIndex(s, sep []byte) int func LastIndexAny(s []byte, chars string) int func LastIndexFunc(s []byte, f func(r rune) bool) int Searching for the last occurrence of a byte is quite common for string parsing algorithms (e.g. find the last paren on a line). Also addition of LastIndexByte makes the set more orthogonal. Change-Id: Ida168849acacf8e78dd70c1354bef9eac5effafe Reviewed-on: https://go-review.googlesource.com/9500Reviewed-by: Rob Pike <r@golang.org>
-
Alex Brainman authored
This CL copies golang.org/x/sys/windows/registry into internal/syscall/windows/registry (minus KeyInfo.ModTime to prevent dependency cycles). New registry package is used in mime and time packages instead of calling Windows API directly. Change-Id: I965a5a41d4739b3ba38e539a7b8d96d3223e3d56 Reviewed-on: https://go-review.googlesource.com/9271Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Bryan Ford authored
This change adds Int.ModSqrt to compute modular square-roots via the standard Tonelli-Shanks algorithm, and the Jacobi function that this and many other modular-arithmetic algorithms depend on. This is needed by change 1883 (https://golang.org/cl/1883), to add support for ANSI-standard compressed encoding of elliptic curve points. Change-Id: Icc4805001bba0b3cb7200e0b0a7f87b14a9e9439 Reviewed-on: https://go-review.googlesource.com/1886Reviewed-by: Adam Langley <agl@golang.org>
-
Adam Langley authored
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>
-
Adam Langley authored
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>
-
Adam Langley authored
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>
-
Ian Lance Taylor authored
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>
-
Mikio Hara authored
Change-Id: I6cebaf42f2596c7f8fef3a67afb1e5ccb428d09c Reviewed-on: https://go-review.googlesource.com/9521Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Josh Bleecher Snyder authored
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>
-
- 29 Apr, 2015 10 commits
-
-
Brad Fitzpatrick authored
Fixes #8840 Change-Id: I194d0248734c15336f91a6bcf57ffcc9c0a3a435 Reviewed-on: https://go-review.googlesource.com/9434Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Michael Hudson-Doyle authored
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>
-
Mikio Hara authored
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>
-
Josh Bleecher Snyder authored
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>
-
Mikio Hara authored
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>
-
Mikio Hara authored
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>
-
Rob Pike authored
Change-Id: I7b15c027c15eefc2a004eb61491e828a7fbefc54 Reviewed-on: https://go-review.googlesource.com/9513Reviewed-by: Russ Cox <rsc@golang.org>
-
Peter Waldschmidt authored
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>
-
Mikio Hara authored
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>
-
Brad Fitzpatrick authored
Change-Id: I77887d247d3e5d60305fc76f962652268827b955 Reviewed-on: https://go-review.googlesource.com/9516Reviewed-by: David Crawshaw <crawshaw@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
-