1. 11 Feb, 2015 3 commits
    • Dmitry Vyukov's avatar
      runtime: fix span unusedsince setup · e604c6e2
      Dmitry Vyukov authored
      Update #8832
      
      This is probably not the root cause of the issue.
      Resolve TODO about setting unusedsince on a wrong span.
      
      Change-Id: I69c87e3d93cb025e3e6fa80a8cffba6ad6ad1395
      Reviewed-on: https://go-review.googlesource.com/4390Reviewed-by: 's avatarKeith Randall <khr@golang.org>
      e604c6e2
    • Austin Clements's avatar
      cmd/dist: fetch version when needed, instead of at init · f3b73e04
      Austin Clements authored
      Currently, if there is a VERSION.cache, running make.bash will set
      runtime.theVersion to the revision as of the *last* make.bash run
      instead of the current make.bash run.
      
      For example,
      
      $ git rev-parse --short HEAD
      5c4a86d0
      $ ./make.bash
      ...
      $ cat ../VERSION.cache
      devel +5c4a86d0 Tue Feb 10 01:46:30 2015 +0000
      $ git checkout a1dbb920
      $ ./make.bash
      ...
      $ go version
      go version devel +5c4a86d0 Tue Feb 10 01:46:30 2015 +0000 linux/amd64
      $ ./make.bash
      ...
      $ go version
      go version devel +a1dbb920 Tue Feb 10 02:31:27 2015 +0000 linux/amd64
      
      This happens because go tool dist reads the potentially stale
      VERSION.cache into goversion during early initialization; then cleans,
      which deletes VERSION.cache; then builds the runtime using the stale
      revision read in to goversion.  It isn't until make later in the build
      process, when make.bash invokes go tool dist again, that VERSION.cache
      gets updated with the current revision.
      
      To address this, simply don't bother fetching the version until go
      tool dist needs it and don't bother caching the value in memory.  This
      is more robust since it interacts with cleaning in the expected ways.
      Futhermore, there's no downside to eliminating the in-memory cache;
      the file system cache is perfectly reasonable for the whole three
      times make.bash consults it.
      
      Change-Id: I8c480100e56bb2db0816e8a088177004d9e87973
      Reviewed-on: https://go-review.googlesource.com/4540Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      f3b73e04
    • rubyist's avatar
      crypto/x509: allow matchHostnames to work with absolute domain names · 32304fc9
      rubyist authored
      If an absolute domain name (i.e. ends in a '.' like "example.com.") is used
      with ssl/tls, the certificate will be reported as invalid. In matchHostnames,
      the host and patterns are split on '.' and if the lengths of the resulting
      slices do not match, the function returns false. When splitting an absolute
      domain name on '.', the slice will have an extra empty string at the end. This
      empty string should be discarded before comparison, if present.
      
      Fixes #9828
      
      Change-Id: I0e39674b44a6f93b5024497e76cf1b550832a61d
      Reviewed-on: https://go-review.googlesource.com/4380Reviewed-by: 's avatarAdam Langley <agl@golang.org>
      TryBot: Adam Langley <agl@golang.org>
      32304fc9
  2. 10 Feb, 2015 13 commits
  3. 09 Feb, 2015 9 commits
  4. 08 Feb, 2015 7 commits
  5. 07 Feb, 2015 5 commits
  6. 06 Feb, 2015 3 commits