| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: I1d19c9f720ba936213448bbbc22d795c8166eebc
|
|
Change-Id: Idf5f9d00388b0da77f2c2ce3650eb65271bd9e68
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/526996
Reviewed-by: Filippo Valsorda <valsorda@google.com>
|
|
Change-Id: I0daab6cd347e1fc0066e516f02c33f1b63e3f1a3
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/526992
Reviewed-by: Filippo Valsorda <valsorda@google.com>
(cherry picked from commit 685bfb1adec3d9fcb589f35eb2bc0b99d2f84bf0)
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/526994
|
|
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/+/189258
Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit 61bb56ad63992a3199acc55b2537c8355ef887b6)
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/526408
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
(cherry picked from commit 3226f2d492963d361af9dfc6714ef141ba606713)
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/526409
|
|
security fix
Apply the following unpublished golang.org/x/net commit.
commit b1cc14aba47abf96f96818003fa4caad3a4b4e86
Author: Filippo Valsorda <filippo@golang.org>
Date: Sun Aug 11 02:12:18 2019 -0400
[release-branch.go1.11] 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/+/525552
Reviewed-by: Brad Fitzpatrick <bradfitz@google.com>
(cherry picked from commit 589ad6cc5321fb68a90370348a241a5da0a2cc80)
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/526070
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Fixes CVE-2019-9512 and CVE-2019-9514
Updates #33606
Change-Id: Iecedf1cc63ec7a1cd75661ec591d91ebc911cc64
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/526072
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
|
|
Change-Id: I0737f9cf175f2e2fe4b1208e7d1635fb4c0c9560
|
|
Change-Id: I7d61b51d4b1b522315370bd17483feab24a2c7bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/185260
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Alexander Rakoczy <alex@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Change-Id: I1b2e369befc58b3f88ac201442a2d9f76d87d54e
Reviewed-on: https://go-review.googlesource.com/c/go/+/185257
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
(cherry picked from commit 0fddd668671c44a622be7d7ea71962be644d8218)
Reviewed-on: https://go-review.googlesource.com/c/go/+/185143
|
|
rewrite rules
A missing operand to mergePoint caused lower to place values
in the wrong blocks.
Includes test, belt+suspenders to do both ssa check and verify
the output (was is how the bug was originally observed).
The fixed bug here is very likely present in Go versions
1.9-1.12 on amd64 and s390x
Updates #32680.
Fixes #32711.
Change-Id: I63e702c4c40602cb795ef71b1691eb704d38ccc7
Reviewed-on: https://go-review.googlesource.com/c/go/+/183059
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
(cherry picked from commit 769fda2d5110eef6146d7df3bf0219872c9b0da6)
Reviewed-on: https://go-review.googlesource.com/c/go/+/183242
|
|
Tweak the previous fix for issue 32673 (in CL 182958) to work around
problems with c-shared build mode that crop up on some of the builders
(10.11, 10.12). We now consistently set vmaddr and vmsize to zero
for the DWARF segment regardless of build mode.
Fixes #32696.
Change-Id: Id1fc213590ad00c28352925e2d754d760e022b5e
Reviewed-on: https://go-review.googlesource.com/c/go/+/183237
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/183400
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
__DWARF segment
For later versions of MacOS, the dynamic loader is more picky about
enforcing restrictions on __DWARF MachO load commands/segments,
triggering aborts of the form
dyld: malformed mach-o image: segment __DWARF has vmsize < filesize
for Go programs that use cgo on Darwin. The error is being triggered
because the Go linker is setting "vmsize" in the DWARF segment entry
to zero as a way to signal that the DWARF doesn't need to be mapped
into memory at runtime (which we need to continue to do).
This patch changes the initial protection on the __DWARF segment to
zero, which dyld seems to be happy with (this is used for other similar
non-loadable sections such as __LLVM).
Updates #32696
Change-Id: I9a73449c6d26c172f3d70361719943af381f37e6
Reviewed-on: https://go-review.googlesource.com/c/go/+/182958
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/183399
|
|
For int8, int16, and int32, comparing their unsigned value to MaxInt64
to determine non-negativity doesn't make sense, because they have
negative values whose unsigned representation is smaller than that.
Fix is simply to compare with the appropriate upper bound based on the
value type's size.
Fixes #32582.
Change-Id: Ie7afad7a56af92bd890ba5ff33c86d1df06cfd9a
Reviewed-on: https://go-review.googlesource.com/c/go/+/181797
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(cherry picked from commit f44404ebbfeff57f3e45ebf4b314a320bb89841f)
Reviewed-on: https://go-review.googlesource.com/c/go/+/181979
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
Change-Id: Ib34dd423b6d83a7e5d0c1f9d7be638aa892fa28c
|
|
Change-Id: If078ff25a79a18429e3383207eae32bb9c8aec12
Reviewed-on: https://go-review.googlesource.com/c/go/+/181657
Reviewed-by: Katie Hockman <katie@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Change-Id: I1c3e3305dfee4545a6caedd48243770ab3b28277
Reviewed-on: https://go-review.googlesource.com/c/go/+/181550
Reviewed-by: Filippo Valsorda <filippo@golang.org>
(cherry picked from commit 55453016979124e18d3afb53c9df1590877a3b53)
Reviewed-on: https://go-review.googlesource.com/c/go/+/181597
|
|
CFDictionaryGetValueIfPresent does not take ownership of the value, so
releasing the properties dictionary before passing the value to CFEqual
can crash. Not really clear why this works most of the time.
See https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFMemoryMgmt/Concepts/Ownership.html
Fixes #32281
Updates #28092
Updates #30763
Change-Id: I5ee7ca276b753a48abc3aedfb78b8af68b448dd4
Reviewed-on: https://go-review.googlesource.com/c/go/+/178537
Reviewed-by: Adam Langley <agl@golang.org>
(cherry picked from commit a3d4655c2435e3777c45f09650539b943bab1c66)
Reviewed-on: https://go-review.googlesource.com/c/go/+/179340
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
|
|
Change-Id: Id0cb0233c689fd97aa37870126d19b472bd1b85d
Reviewed-on: https://go-review.googlesource.com/c/go/+/175445
Run-TryBot: Andrew Bonventre <andybons@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Change-Id: Icca4495f727e3921b717a4bbb441cd832d321d46
Reviewed-on: https://go-review.googlesource.com/c/go/+/175439
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit e1f9e701be094741b234320cc49b8776cce27c3f)
Reviewed-on: https://go-review.googlesource.com/c/go/+/175442
Reviewed-by: Andrew Bonventre <andybons@golang.org>
|
|
While many other call sites have been moved to using the proper
higher-level system loading, these areas were left out. This prevents
DLL directory injection attacks. This includes both the runtime load
calls (using LoadLibrary prior) and the implicitly linked ones via
cgo_import_dynamic, which we move to our LoadLibraryEx. The goal is to
only loosely load kernel32.dll and strictly load all others.
Meanwhile we make sure that we never fallback to insecure loading on
older or unpatched systems.
This is CVE-2019-9634.
Fixes #30989
Updates #14959
Updates #28978
Updates #30642
Change-Id: I401a13ed8db248ab1bb5039bf2d31915cac72b93
Reviewed-on: https://go-review.googlesource.com/c/go/+/165798
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
(cherry picked from commit 9b6e9f0c8c66355c0f0575d808b32f52c8c6d21c)
Reviewed-on: https://go-review.googlesource.com/c/go/+/175378
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Andrew Bonventre <andybons@golang.org>
|
|
TestSectionsWithSameName
The test doesn't really require cgo, but it does require that we know
the right flags to use to run the C compiler, and that is not
necessarily correct if we don't support cgo.
Fixes #31565
Change-Id: I04dc8db26697caa470e91ad712376aa621cf765d
Reviewed-on: https://go-review.googlesource.com/c/go/+/172981
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(cherry picked from commit 4c236b9b097882f3aef8116e1ac9f65463bf6f01)
Reviewed-on: https://go-review.googlesource.com/c/go/+/173118
|
|
the same name
New versions of clang can generate multiple sections named ".text"
when using vague C++ linkage. This is valid ELF, but would cause the
Go linker to report an error when using internal linking:
symbol PACKAGEPATH(.text) listed multiple times
Avoid the problem by renaming section symbol names if there is a name
collision.
Change-Id: I41127e95003d5b4554aaf849177b3fe000382c02
Reviewed-on: https://go-review.googlesource.com/c/go/+/172697
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
(cherry picked from commit 3235f7c0720338a160debe6e9c632b8af968b4dd)
Reviewed-on: https://go-review.googlesource.com/c/go/+/172702
|
|
Change-Id: If4ab7c431f11a2d3db677b323dd85e0e8ce6de03
Reviewed-on: https://go-review.googlesource.com/c/go/+/171837
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Updates #31293
Change-Id: I3d72f732be7b28059310ea6fc134c3bfac81492d
Reviewed-on: https://go-review.googlesource.com/c/go/+/171578
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
(cherry picked from commit ab2a0803383f0f019db0b2252095f2fdb7735cea)
Reviewed-on: https://go-review.googlesource.com/c/go/+/171767
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
Change-Id: Ie15c45050f817213b3f5955dc98b48a6cf2a6317
Reviewed-on: https://go-review.googlesource.com/c/go/+/171148
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Change-Id: I09e0c2720ec0a51dc73c24b4550a749448656025
Reviewed-on: https://go-review.googlesource.com/c/go/+/171143
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 6f512c8d6696b288372c48c19058bbe9dcb79da0)
Reviewed-on: https://go-review.googlesource.com/c/go/+/171146
Reviewed-by: Andrew Bonventre <andybons@golang.org>
|
|
Change-Id: Ia06f7005f466e55a22c76bf2b47d74ee8eb77dd1
Reviewed-on: https://go-review.googlesource.com/c/go/+/171139
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 739a78f2b8de3139ec253719d0a688c08b8e5324)
Reviewed-on: https://go-review.googlesource.com/c/go/+/171142
Reviewed-by: Andrew Bonventre <andybons@golang.org>
|
|
Change-Id: I14c2be9eedb5332d0b3a66029a86f7cb9e6091cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/170889
Run-TryBot: Andrew Bonventre <andybons@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Change-Id: Iec5e69b3ea163f42234d3b73696427a7aa8732e3
Reviewed-on: https://go-review.googlesource.com/c/go/+/170884
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit e47ced78578c471cbcd34a7d6b223a71e84a46c8)
Reviewed-on: https://go-review.googlesource.com/c/go/+/170887
Reviewed-by: Andrew Bonventre <andybons@golang.org>
|
|
Change-Id: If16bb7da36d998ba6c8d5dc244d0c9febd7c3bf3
|
|
Google's 8.8.8.8 DNS server used to reports its reverse DNS name
as ending in ".google.com". Now it's "dns.google.".
Change-Id: I7dd15f03239e5c3f202e471618ab867690cb4f9d
Reviewed-on: https://go-review.googlesource.com/c/go/+/169679
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
(cherry picked from commit 3089d189569ed272eaf2bc6c4330e848a46e9999)
Reviewed-on: https://go-review.googlesource.com/c/go/+/169718
|
|
The current wasm write barrier implementation incorrectly implements
the "deletion" part of the barrier. It correctly greys the new value
of the pointer, but rather than also greying the old value of the
pointer, it greys the object containing the slot (which, since the old
value was just overwritten, is not going to contain the old value).
This can lead to unmarked, reachable objects.
Often, this is masked by other marking activity, but one specific
sequence that can lead to an unmarked object because of this bug is:
1. Initially, GC is off, object A is reachable from just one pointer
in the heap.
2. GC starts and scans the stack of goroutine G.
3. G copies the pointer to A on to its stack and overwrites the
pointer to A in the heap. (Now A is reachable only from G's stack.)
4. GC finishes while A is still reachable from G's stack.
With a functioning deletion barrier, step 3 causes A to be greyed.
Without a functioning deletion barrier, nothing causes A to be greyed,
so A will be freed even though it's still reachable from G's stack.
This CL fixes the wasm write barrier.
Fixes #30872.
Change-Id: I8a74ee517facd3aa9ad606e5424bcf8f0d78e754
Reviewed-on: https://go-review.googlesource.com/c/go/+/167743
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
(cherry picked from commit d9db9e32e924a60bbfbb15cc0dd7cfaaf8a62a3b)
Reviewed-on: https://go-review.googlesource.com/c/go/+/167746
Reviewed-by: Katie Hockman <katie@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Change-Id: I944d7cb825b8791486446d78feae9eed0a5479c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/167705
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Bonventre <andybons@golang.org>
|
|
if one can't unshare
This change splits a testprog out of TestLockOSThreadExit and makes it
its own test. Then, this change makes the testprog exit prematurely with
a special message if unshare fails with EPERM because not all of the
builders allow the user to call the unshare syscall.
Also, do some minor cleanup on the TestLockOSThread* tests.
Fixes #29366.
Change-Id: Id8a9f6c4b16e26af92ed2916b90b0249ba226dbe
Reviewed-on: https://go-review.googlesource.com/c/155437
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 429bae715876c69853bb63db1733f580e293c916)
Reviewed-on: https://go-review.googlesource.com/c/go/+/167707
Run-TryBot: Andrew Bonventre <andybons@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
|
Change-Id: I99832fa4f2c3ec28e2dad46cf7607f3766948031
Reviewed-on: https://go-review.googlesource.com/c/go/+/167698
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit d3bb45d9046bb7d12c4fc9cdaf122f36d001fd31)
Reviewed-on: https://go-review.googlesource.com/c/go/+/167700
|
|
After CL 128056 the build fails on darwin/386 with
src/crypto/x509/root_cgo_darwin.go:218:55: warning: values of type 'SInt32' should not be used as format arguments; add an explicit cast to 'int' instead [-Wformat]
go build crypto/x509: C compiler warning promoted to error on Go builders
Fix the warning by explicitly casting the argument to an int as
suggested by the warning.
Fixes #30444
Change-Id: Icb6bd622a543e9bc5f669fd3d7abd418b4a8e579
Reviewed-on: https://go-review.googlesource.com/c/152958
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit ec0077c54d6261ba5cbab2c5dc2e80345068233f)
Reviewed-on: https://go-review.googlesource.com/c/164240
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
no match
If a certificate somehow has an AKID, it should still chain successfully
to a parent without a SKID, even if the latter is invalid according to
RFC 5280, because only the Subject is authoritative.
This reverts to the behavior before #29233 was fixed in 770130659. Roots
with the right subject will still be shadowed by roots with the right
SKID and the wrong subject, but that's been the case for a long time, and
is left for a more complete fix in Go 1.13.
Updates #30079
Fixes #30081
Change-Id: If8ab0179aca86cb74caa926d1ef93fb5e416b4bb
Reviewed-on: https://go-review.googlesource.com/c/161097
Reviewed-by: Adam Langley <agl@golang.org>
(cherry picked from commit 95e5b07cf5fdf3352f04f5557df38f22c55ce8e8)
Reviewed-on: https://go-review.googlesource.com/c/163739
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
in prove pass
In the case of x+d >= w, where d and w are constants, we are
deriving x is within the bound of min=w-d and max=maxInt-d. When
there is an overflow (min >= max), we know only one of x >= min
or x <= max is true, and we derive this by excluding the other.
When excluding x >= min, we did not consider the equal case, so
we could incorrectly derive x <= max when x == min.
Updates #29502.
Fixes #29503.
Change-Id: Ia9f7d814264b1a3ddf78f52e2ce23377450e6e8a
Reviewed-on: https://go-review.googlesource.com/c/156019
Reviewed-by: David Chase <drchase@google.com>
(cherry picked from commit 2e217fa726a624093eea5b099d1531c79e27a423)
Reviewed-on: https://go-review.googlesource.com/c/163724
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
path)
Certificates without any trust settings might still be in the keychain
(for example if they used to have some, or if they are intermediates for
offline verification), but they are not to be trusted. The only ones we
can trust unconditionally are the ones in the system roots store.
Moreover, the verify-cert invocation was not specifying the ssl policy,
defaulting instead to the basic one. We have no way of communicating
different usages in a CertPool, so stick to the WebPKI use-case as the
primary one for crypto/x509.
Updates #24652
Fixes #26039
Change-Id: Ife8b3d2f4026daa1223aa81fac44aeeb4f96528a
Reviewed-on: https://go-review.googlesource.com/c/128116
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@golang.org>
(cherry picked from commit aa2415807781ba84bf917c62cb983dc1a44f2ad1)
Reviewed-on: https://go-review.googlesource.com/c/162861
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Bonventre <andybons@golang.org>
|
|
The cgo path was not taking policies into account, using the last
security setting in the array whatever it was. Also, it was not aware of
the defaults for empty security settings, and for security settings
without a result type. Finally, certificates restricted to a hostname
were considered roots.
The API docs for this code are partial and not very clear, so this is a
best effort, really.
Updates #24652
Updates #26039
Change-Id: I8fa2fe4706f44f3d963b32e0615d149e997b537d
Reviewed-on: https://go-review.googlesource.com/c/128056
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@golang.org>
(cherry picked from commit f6be1cf109a2be59b96d1fa913adfa1fbc628579)
Reviewed-on: https://go-review.googlesource.com/c/162860
Reviewed-by: Andrew Bonventre <andybons@golang.org>
|
|
CL 159859 causes build failure with old clang versions (3.4.1) on FreeBSD 10.3/10.4.
Update #29962
Reviewed-on: https://go-review.googlesource.com/c/160777
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit 6f4dc1ccf9735013fdb7cd044bda29d19bebb906)
Change-Id: Ie78d552ea6494fe3c4059847b26c2a6e206f9515
Reviewed-on: https://go-review.googlesource.com/c/160780
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
GCC 9 has started emitting warnings when taking the address of a field
in a packed struct may cause a misaligned pointer. We use packed
structs in cgo to ensure that our field layout matches the C
compiler's layout. Our pointers are always aligned, so disable the warning
Updates #29962
Fixes #29967
Change-Id: I7e290a7cf694a2c2958529e340ebed9fcd62089c
Reviewed-on: https://go-review.googlesource.com/c/159859
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
(cherry picked from commit f2a416b90ac68596ea05b97cefa8c72e7416e98f)
Reviewed-on: https://go-review.googlesource.com/c/160449
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Cherry pick of combined CL 159157 + CL 160178.
Fixes #29923
Updates #27302
Updates #22907
Change-Id: I6de92c14284595a58321a4b4d53229285979b872
Reviewed-on: https://go-review.googlesource.com/c/160798
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
values
The in-tree GDB is too old (6.1.1) on all the builders except the
FreeBSD 12.0 one, where it was removed from the base system.
Update #29508
Change-Id: Ib6091cd86440ea005f3f903549a0223a96621a6f
Reviewed-on: https://go-review.googlesource.com/c/156717
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/160800
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Yuval Pavel Zholkover <paulzhol@gmail.com>
|
|
Change-Id: I798d95666c47746412a28c458a4cda0f0a9d79c6
|
|
release-branch.go1.11
Change-Id: Ic59638be13c6dadeccd5974ec6cd9ef4b5b4b526
|
|
Change-Id: Ib957fc19ae0633f77e2a5a9219f7a11ceda3f092
Reviewed-on: https://team-review.git.corp.google.com/c/400909
Reviewed-by: Filippo Valsorda <valsorda@google.com>
|
|
TestLookupGmailTXT
Fixes #29698
Change-Id: I0531c0a274b120af8871aa2f5975744ff6c912a3
Reviewed-on: https://go-review.googlesource.com/c/157638
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-on: https://team-review.git.corp.google.com/c/401203
Reviewed-by: Filippo Valsorda <valsorda@google.com>
|
|
Change-Id: I97ce42e1e9a6d10bf1eeccc2763e043d8ebe5bab
Reviewed-on: https://team-review.git.corp.google.com/c/400906
Reviewed-by: Filippo Valsorda <valsorda@google.com>
(cherry picked from commit efe766c7c0918da96aa21e1ac03a9d3fa57ca156)
Reviewed-on: https://team-review.git.corp.google.com/c/401144
|
|
prevent long busy loop
If beta8 is unusually large, the addition loop might take a very long
time to bring x3-beta8 back positive.
This would lead to a DoS vulnerability in the implementation of the
P-521 and P-384 elliptic curves that may let an attacker craft inputs
to ScalarMult that consume excessive amounts of CPU.
This fixes CVE-2019-6486.
Change-Id: Ia969e8b5bf5ac4071a00722de9d5e4d856d8071a
Reviewed-on: https://team-review.git.corp.google.com/c/399777
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: Julie Qiu <julieqiu@google.com>
(cherry picked from commit 746d6abe2dfb9ce7609f8e1e1a8dcb7e221f423e)
Reviewed-on: https://team-review.git.corp.google.com/c/401142
Reviewed-by: Filippo Valsorda <valsorda@google.com>
|
|
TestLookupGmailTXT
Updates #29698
Fixes #29700
Change-Id: I0531c0a274b120af8871aa2f5975744ff6c912a3
Reviewed-on: https://go-review.googlesource.com/c/157638
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 7cbfa55b5d17c8deaecff05e4221f828467cfa97)
Reviewed-on: https://go-review.googlesource.com/c/157639
|
