1. 30 Apr, 2015 19 commits
    • Alex A Skinner's avatar
      net: make go DNS use localhost if resolv.conf is missing or empty · f3901357
      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: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      f3901357
    • Michael Hudson-Doyle's avatar
      cmd/internal/ld: put the list of packages built into a shared library into an ELF note · 7556948e
      Michael Hudson-Doyle authored
      Change-Id: I611f7dec2109dc7e2f090ced0a1dca3d4b577134
      Reviewed-on: https://go-review.googlesource.com/9520Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      Run-TryBot: Ian Lance Taylor <iant@golang.org>
      7556948e
    • Dave Cheney's avatar
      misc/cgo/testcshared, misc/cgo/testshared: fix clang warnings and errors · ccaaf1f1
      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: default avatarIan Lance Taylor <iant@golang.org>
      ccaaf1f1
    • Ian Lance Taylor's avatar
      cmd/go, cmd/cgo: support -buildmode=c-archive for gccgo · 42bb59a3
      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: default avatarDavid Crawshaw <crawshaw@golang.org>
      42bb59a3
    • Didier Spezia's avatar
      html/template: fix quadratic performance with special tags · f4e3e5ea
      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: default avatarRob Pike <r@golang.org>
      f4e3e5ea
    • Russ Cox's avatar
      runtime: schedule GC work more aggressively · 79a990b8
      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: default avatarAustin Clements <austin@google.com>
      79a990b8
    • Josh Bleecher Snyder's avatar
      doc/go1.5.txt: add Jacobi and Int.ModSqrt to math/big · a593a36b
      Josh Bleecher Snyder authored
      Change-Id: I187e97592cd0403d84ca25c4acb1a4b25495041b
      Reviewed-on: https://go-review.googlesource.com/9534Reviewed-by: default avatarJosh Bleecher Snyder <josharian@gmail.com>
      a593a36b
    • Austin Clements's avatar
      runtime: fix gcDumpObject on non-heap pointers · 3ca20218
      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: default avatarRick Hudson <rlh@golang.org>
      3ca20218
    • Dmitry Vyukov's avatar
      strings: use LastIndexByte in LastIndex · cfb8b18e
      Dmitry Vyukov authored
      Change-Id: I1add1b92f5c2688a99133d90bf9789d770fd9f05
      Reviewed-on: https://go-review.googlesource.com/9503Reviewed-by: default avatarMatthew Dempsky <mdempsky@google.com>
      cfb8b18e
    • Dmitry Vyukov's avatar
      doc/go1.5.txt: bytes, strings: add LastIndexByte · 09edc5c6
      Dmitry Vyukov authored
      Change-Id: I05cfacd746e87011de8b659ab3b2fbe23146a7f3
      Reviewed-on: https://go-review.googlesource.com/9504Reviewed-by: default avatarDmitry Vyukov <dvyukov@google.com>
      09edc5c6
    • Dmitry Vyukov's avatar
      bytes, strings: add LastIndexByte · 0fb5475b
      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: default avatarRob Pike <r@golang.org>
      0fb5475b
    • Alex Brainman's avatar
      mime, time, internal/syscall/windows/registry: use new registry package to simplify code · 89454b1c
      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: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      89454b1c
    • Bryan Ford's avatar
      math/big: add modular square-root and Jacobi functions · ac615882
      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: default avatarAdam Langley <agl@golang.org>
      ac615882
    • Adam Langley's avatar
      crypto/x509: be strict about trailing data. · 1ddb8c20
      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: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      Reviewed-by: default avatarAdam Langley <agl@golang.org>
      1ddb8c20
    • Adam Langley's avatar
      crypto/tls: update the supported signature algorithms. · 1c105980
      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: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      1c105980
    • Adam Langley's avatar
      crypto/tls: decouple handshake signatures from the handshake hash. · 09b238f1
      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: default avatarAdam Langley <agl@golang.org>
      09b238f1
    • Ian Lance Taylor's avatar
      cmd/dist: rename buildmode method to supportedBuildmode · edcc8f9e
      Ian Lance Taylor authored
      Change-Id: Ie36fd46ad3c0799200fdf4240483a207335570d8
      Reviewed-on: https://go-review.googlesource.com/9531Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      Run-TryBot: Ian Lance Taylor <iant@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      edcc8f9e
    • Mikio Hara's avatar
      doc: mention net.OpError in go1.5.txt · 433af05a
      Mikio Hara authored
      Change-Id: I6cebaf42f2596c7f8fef3a67afb1e5ccb428d09c
      Reviewed-on: https://go-review.googlesource.com/9521Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      433af05a
    • Josh Bleecher Snyder's avatar
      src: build cmd in buildall.bash · 9b66cf60
      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: default avatarMichael Hudson-Doyle <michael.hudson@canonical.com>
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      9b66cf60
  2. 29 Apr, 2015 21 commits