1. 07 Jan, 2020 1 commit
  2. 03 Jan, 2020 2 commits
    • Jason A. Donenfeld's avatar
      [release-branch.go1.12] runtime: do not use... · e42221dc
      Jason A. Donenfeld authored
      [release-branch.go1.12] runtime: do not use PowerRegisterSuspendResumeNotification on systems with "program time" timer
      
      Systems where PowerRegisterSuspendResumeNotification returns ERROR_
      FILE_NOT_FOUND are also systems where nanotime() is on "program time"
      rather than "real time".  The chain for this is:
      
      powrprof.dll!PowerRegisterSuspendResumeNotification ->
        umpdc.dll!PdcPortOpen ->
          ntdll.dll!ZwAlpcConnectPort("\\PdcPort") ->
            syscall -> ntoskrnl.exe!AlpcpConnectPort
      
      Opening \\.\PdcPort fails with STATUS_OBJECT_NAME_NOT_FOUND when pdc.sys
      hasn't been initialized. Pdc.sys also provides the various hooks for
      sleep resumption events, which means if it's not loaded, then our "real
      time" timer is actually on "program time". Finally STATUS_OBJECT_NAME_
      NOT_FOUND is passed through RtlNtStatusToDosError, which returns ERROR_
      FILE_NOT_FOUND. Therefore, in the case where the function returns ERROR_
      FILE_NOT_FOUND, we don't mind, since the timer we're using will
      correspond fine with the lack of sleep resumption notifications. This
      applies, for example, to Docker users.
      
      Updates #35447
      Updates #35482
      Fixes #36377
      
      Change-Id: I9e1ce5bbc54b9da55ff7a3918b5da28112647eee
      Reviewed-on: https://go-review.googlesource.com/c/go/+/208317Reviewed-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Reviewed-by: default avatarAustin Clements <austin@google.com>
      Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-on: https://go-review.googlesource.com/c/go/+/213198
      e42221dc
    • Jason A. Donenfeld's avatar
      [release-branch.go1.12] runtime: monitor for suspend/resume to kick timeouts · 93f05994
      Jason A. Donenfeld authored
      Starting in Windows 8, the wait functions don't take into account
      suspend time, even though the monotonic counters do. This results in
      timer buckets stalling on resume. Therefore, this commit makes it so
      that on resume, we return from the wait functions and recalculate the
      amount of time left to wait.
      
      This is a cherry pick of CL 191957 and its cleanup, CL 198417.
      
      Updates #31528
      Fixes #36376
      
      Change-Id: I0db02cc72188cb620954e87a0180e0a3c83f4a56
      Reviewed-on: https://go-review.googlesource.com/c/go/+/193607
      Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarAustin Clements <austin@google.com>
      Reviewed-on: https://go-review.googlesource.com/c/go/+/213197
      93f05994
  3. 11 Dec, 2019 1 commit
  4. 09 Dec, 2019 1 commit
    • Dmitri Shuralyov's avatar
      [release-branch.go1.12] doc: add CherryPickApproved filter to Release History links · 741cb42f
      Dmitri Shuralyov authored
      Not all closed issues in a given minor milestone are included in that
      release, only the ones that have been labeled as CherryPickApproved are.
      
      Update the links to the GitHub issue tracker to include a filter on the
      CherryPickApproved label, so that the default view shows only the
      backports that were included in a given release. This should more useful
      to most people than seeing all backports (considered and approved).
      
      Do this only for Go 1.9.1 and newer releases, as that is when we started
      using the CherryPickCandidate and CherryPickApproved labels.
      
      Updates #35988
      Fixes #36002
      
      Change-Id: I51e07c1bc3ab9c4a5744e8f668c5470adf78bffe
      Reviewed-on: https://go-review.googlesource.com/c/go/+/210118
      Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
      Reviewed-by: default avatarAlexander Rakoczy <alex@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      741cb42f
  5. 04 Dec, 2019 4 commits
  6. 22 Nov, 2019 1 commit
  7. 21 Nov, 2019 1 commit
    • Andrew's avatar
      [release-branch.go1.12] all: base64-encode binaries that will cause Apple notarization to fail · a106f553
      Andrew authored
      Starting with macOS 10.15 (Catalina), Apple now requires all software
      distributed outside of the App Store to be notarized. Any binaries we
      distribute must abide by a strict set of requirements like code-signing
      and having a minimum target SDK of 10.9 (amongst others).
      
      Apple’s notarization service will recursively inspect archives looking to
      find notarization candidate binaries. If it finds a binary that does not
      meet the requirements or is unable to decompress an archive, it will
      reject the entire distribution. From cursory testing, it seems that the
      service uses content sniffing to determine file types, so changing
      the file extension will not work.
      
      There are some binaries and archives included in our distribution that
      are being detected by Apple’s service as potential candidates for
      notarization or decompression. As these are files used by tests and some
      are intentionally invalid, we don’t intend to ever make them compliant.
      
      As a workaround for this, we base64-encode any binaries or archives that
      Apple’s notarization service issues a warning for, as these warnings will
      become errors in January 2020.
      
      Updates #34986
      Updates #35747
      
      Change-Id: I106fbb6227b61eb221755568f047ee11103c1680
      Reviewed-on: https://go-review.googlesource.com/c/go/+/208118
      Run-TryBot: Andrew Bonventre <andybons@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      (cherry picked from commit 8bbfc51d)
      Reviewed-on: https://go-review.googlesource.com/c/go/+/208220Reviewed-by: default avatarAlexander Rakoczy <alex@golang.org>
      a106f553
  8. 31 Oct, 2019 2 commits
  9. 17 Oct, 2019 5 commits
  10. 16 Oct, 2019 1 commit
  11. 09 Oct, 2019 4 commits
  12. 08 Oct, 2019 1 commit
  13. 03 Oct, 2019 1 commit
  14. 26 Sep, 2019 1 commit
  15. 25 Sep, 2019 3 commits
  16. 06 Sep, 2019 1 commit
  17. 26 Aug, 2019 1 commit
  18. 15 Aug, 2019 2 commits
  19. 13 Aug, 2019 3 commits
  20. 12 Aug, 2019 2 commits
    • Filippo Valsorda's avatar
      [release-branch.go1.12-security] net/url: make Hostname and Port predictable... · 3226f2d4
      Filippo Valsorda authored
      [release-branch.go1.12-security] net/url: make Hostname and Port predictable for invalid Host values
      
      When Host is not valid per RFC 3986, the behavior of Hostname and Port
      was wildly unpredictable, to the point that Host could have a suffix
      that didn't appear in neither Hostname nor Port.
      
      This is a security issue when applications are applying checks to Host
      and expecting them to be meaningful for the contents of Hostname.
      
      To reduce disruption, this change only aims to guarantee the following
      two security-relevant invariants.
      
      * Host is either Hostname or [Hostname] with Port empty, or
        Hostname:Port or [Hostname]:Port.
      
      * Port is only decimals.
      
      The second invariant is the one that's most likely to cause disruption,
      but I believe it's important, as it's conceivable an application might
      do a suffix check on Host and expect it to be meaningful for the
      contents of Hostname (if the suffix is not a valid port).
      
      There are three ways to ensure it.
      
      1) Reject invalid ports in Parse. Note that non-numeric ports are
         already rejected if and only if the host starts with "[".
      
      2) Consider non-numeric ports as part of Hostname, not Port.
      
      3) Allow non-numeric ports, and hope they only flow down to net/http,
         which will reject them (#14353).
      
      This change adopts both 1 and 2. We could do only the latter, but then
      these invalid hosts would flow past port checks, like in
      http_test.TestTransportRejectsAlphaPort. Non-numeric ports weren't fully
      supported anyway, because they were rejected after IPv6 literals, so
      this restores consistency. We could do only the former, but at this
      point 2) is free and might help with manually constructed Host values
      (or if we get something wrong in Parse).
      
      Note that net.SplitHostPort and net.Dial explicitly accept service names
      in place of port numbers, but this is an URL package, and RFC 3986,
      Section 3.2.3, clearly specifies ports as a number in decimal.
      
      net/http uses a mix of net.SplitHostPort and url.Parse that would
      deserve looking into, but in general it seems that it will still accept
      service names in Addr fields as they are passed to net.Listen, while
      rejecting them in URLs, which feels correct.
      
      This leaves a number of invalid URLs to reject, which however are not
      security relevant once the two invariants above hold, so can be done in
      Go 1.14: IPv6 literals without brackets (#31024), invalid IPv6 literals,
      hostnames with invalid characters, and more.
      
      Tested with 200M executions of go-fuzz and the following Fuzz function.
      
      	u, err := url.Parse(string(data))
      	if err != nil {
      		return 0
      	}
      	h := u.Hostname()
      	p := u.Port()
      
      	switch u.Host {
      	case h + ":" + p:
      		return 1
      	case "[" + h + "]:" + p:
      		return 1
      	case h:
      		fallthrough
      	case "[" + h + "]":
      		if p != "" {
      			panic("unexpected Port()")
      		}
      		return 1
      	}
      	panic("Host is not a variant of [Hostname]:Port")
      
      Fixes CVE-2019-14809
      Updates #29098
      
      Change-Id: I7ef40823dab28f29511329fa2d5a7fb10c3ec895
      Reviewed-on: https://go-review.googlesource.com/c/go/+/189258Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      (cherry picked from commit 61bb56ad)
      Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/526408Reviewed-by: default avatarDmitri Shuralyov <dmitshur@google.com>
      3226f2d4
    • Filippo Valsorda's avatar
      [release-branch.go1.12-security] net/http: update bundled http2 to import security fix · 7139b45d
      Filippo Valsorda authored
      Apply the following unpublished golang.org/x/net commit.
      
          commit cdfb69ac37fc6fa907650654115ebebb3aae2087
          Author: Filippo Valsorda <filippo@golang.org>
          Date:   Sun Aug 11 02:12:18 2019 -0400
      
          [release-branch.go1.12] http2: limit number of control frames in server send queue
      
          An attacker could cause servers to queue an unlimited number of PING
          ACKs or RST_STREAM frames by soliciting them and not reading them, until
          the program runs out of memory.
      
          Limit control frames in the queue to a few thousands (matching the limit
          imposed by other vendors) by counting as they enter and exit the scheduler,
          so the protection will work with any WriteScheduler.
      
          Once the limit is exceeded, close the connection, as we have no way to
          communicate with the peer.
      
          Change-Id: I842968fc6ed3eac654b497ade8cea86f7267886b
          Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/525552Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@google.com>
          (cherry picked from commit 589ad6cc5321fb68a90370348a241a5da0a2cc80)
          Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/526069Reviewed-by: default avatarDmitri Shuralyov <dmitshur@google.com>
      
      Fixes CVE-2019-9512 and CVE-2019-9514
      Updates #33606
      
      Change-Id: I282b3e0fa22422d9ea0d07f4a3935685ce4a7433
      Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/526071Reviewed-by: default avatarDmitri Shuralyov <dmitshur@google.com>
      7139b45d
  21. 09 Aug, 2019 1 commit
  22. 02 Aug, 2019 1 commit