The file is used by assembly code to define symbols like NOSPLIT.
Having it hidden inside the cmd directory makes it hard to access
outside the standard repository.
Solution: As with a couple of other files used by cgo, copy the
file into the pkg directory and add a -I argument to the assembler
to access it. Thus one can write just
#include "textflag.h"
in .s files.
The names in runtime are not updated because in the boot sequence the
file has not been copied yet when runtime is built. All other .s files
in the repository are updated.
Changes to doc/asm.html, src/cmd/dist/build.c, and src/cmd/go/build.go
are hand-made. The rest are just the renaming done by a global
substitution. (Yay sam).
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/128050043
This change causes a TLS client and server to verify that received
elliptic curve points are on the expected curve. This isn't actually
necessary in the Go TLS stack, but Watson Ladd has convinced me that
it's worthwhile because it's pretty cheap and it removes the
possibility that some change in the future (e.g. tls-unique) will
depend on it without the author checking that precondition.
LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/115290046
This is more useful than panicking, since otherwise every caller needs
to do the length check before calling; some will forget, and have a
potential submarine crasher as a result. Other implementations of this
functionality do a length check.
This is backward compatible, except if someone has written code that
relies on this panicking with different length args. However, that was
not the case before Go 1.3 either.
Updates #7304.
LGTM=agl
R=agl, minux, hanwen
CC=golang-codereviews
https://golang.org/cl/118750043
Thanks to Cedric Staub for noting that a short session key would lead
to an out-of-bounds access when conditionally copying the too short
buffer over the random session key.
LGTM=davidben, bradfitz
R=davidben, bradfitz
CC=golang-codereviews
https://golang.org/cl/102670044
Add nacl.bash, the NaCl version of all.bash.
It's a separate script because it builds a variant of package syscall
with a large zip file embedded in it, containing all the input files
needed for tests.
Disable various tests new since the last round, mostly the ones using os/exec.
Fixes#7945.
LGTM=dave
R=golang-codereviews, remyoudompheng, dave, bradfitz
CC=golang-codereviews
https://golang.org/cl/100590044
The function takes 32 bytes of arguments: 8 for the *block
and then 3*8 for the slice.
The 24 is not causing a bug (today at least) because the
final word is the cap of the slice, which the assembly
does not use.
Identified by 'go vet std'.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/96360043
Where the spelling changed from British to
US norm (e.g., optimise -> optimize) it follows
the style in that file.
LGTM=adonovan
R=golang-codereviews, adonovan
CC=golang-codereviews
https://golang.org/cl/96980043
Windows is building a chain to the AddTrust root which is different
from the native Go code and causing a build failure.
This change alters the test so that both should build to the AddTrust
root.
R=bradfitz
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/87570044
Comodo are now using a SHA-384 signed intermediate. The crypto/x509
package seeks to import hash functions needed for typical operation
without needing to import every hash function possible. Since a SHA-384
certificate is being used by Comodo, crypto/sha512 now appears to fall
into the scope of "typical operation".
R=bradfitz
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/87670045
Now that we have a constant-time P-256 implementation, it's worth
paying more attention elsewhere.
The inversion of k in (EC)DSA was using Euclid's algorithm which isn't
constant-time. This change switches to Fermat's algorithm, which is
much better. However, it's important to note that math/big itself isn't
constant time and is using a 4-bit window for exponentiation with
variable memory access patterns.
(Since math/big depends quite deeply on its values being in minimal (as
opposed to fixed-length) represetation, perhaps crypto/elliptic should
grow a constant-time implementation of exponentiation in the scalar
field.)
R=bradfitz
Fixes#7652.
LGTM=rsc
R=golang-codereviews, bradfitz, rsc
CC=golang-codereviews
https://golang.org/cl/82740043
This change sets systemSkip on a test where Go and CAPI have different
chain building behaviour. CAPI is correct, but aligning the Go code is
probably too large a change prior to 1.3.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/81620043
The root update on 3/11/2014 removed the Verisign root cert that the Go
tests use. This only affects the 'TestSystemVerify' test in
crypto/x509.
Fixes#7523.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/80000044
Update #3514
An io.Reader is permitted to return either (n, nil)
or (n, io.EOF) on EOF or other error.
The tls package previously always returned (n, nil) for a read
of size n if n bytes were available, not surfacing errors at
the same time.
Amazon's HTTPS frontends like to hang up on clients without
sending the appropriate HTTP headers. (In their defense,
they're allowed to hang up any time, but generally a server
hangs up after a bit of inactivity, not immediately.) In any
case, the Go HTTP client tries to re-use connections by
looking at whether the response headers say to keep the
connection open, and because the connection looks okay, under
heavy load it's possible we'll reuse it immediately, writing
the next request, just as the Transport's always-reading
goroutine returns from tls.Conn.Read and sees (0, io.EOF).
But because Amazon does send an AlertCloseNotify record before
it hangs up on us, and the tls package does its own internal
buffering (up to 1024 bytes) of pending data, we have the
AlertCloseNotify in an unread buffer when our Conn.Read (to
the HTTP Transport code) reads its final bit of data in the
HTTP response body.
This change makes that final Read return (n, io.EOF) when
an AlertCloseNotify record is buffered right after, if we'd
otherwise return (n, nil).
A dependent change in the HTTP code then notes whether a
client connection has seen an io.EOF and uses that as an
additional signal to not reuse a HTTPS connection. With both
changes, the majority of Amazon request failures go
away. Without either one, 10-20 goroutines hitting the S3 API
leads to such an error rate that empirically up to 5 retries
are needed to complete an API call.
LGTM=agl, rsc
R=agl, rsc
CC=golang-codereviews
https://golang.org/cl/76400046
We provide amd64p32 implementations for md5 and sha1 so we need to exclude amd64p32 from the generic implementations in those packages.
Fixes build once CL 72360044 lands.
LGTM=agl, remyoudompheng
R=rsc, bradfitz, agl, remyoudompheng
CC=golang-codereviews
https://golang.org/cl/72460043
It mentioned true and false for error values. Instead, just
don't mention the error semantics, as they match normal Go
conventions (if error is non-nil, the other value is
meaningless). We generally only document error values when
they're interesting (where non-nil, non-nil is valid, or the
error value can be certain known values or types).
Fixes#7464
LGTM=agl
R=agl
CC=golang-codereviews
https://golang.org/cl/68440044
Currently a write error will cause future reads to return that same error.
However, there may have been extra information from a peer pending on
the read direction that is now unavailable.
This change splits the single connErr into errors for the read, write and
handshake. (Splitting off the handshake error is needed because both read
and write paths check the handshake error.)
Fixes#7414.
LGTM=bradfitz, r
R=golang-codereviews, r, bradfitz
CC=golang-codereviews
https://golang.org/cl/69090044
While reviewing uses of the lower-level Client API in code, I found
that in many cases, code was using Client only because it needed a
timeout on the connection. DialWithDialer allows a timeout (and
other values) to be specified without resorting to the low-level API.
LGTM=r
R=golang-codereviews, r, bradfitz
CC=golang-codereviews
https://golang.org/cl/68920045
See golang.org/s/go13nacl for design overview.
This CL is the mostly mechanical changes from rsc's Go 1.2 based NaCl branch, specifically 39cb35750369 to 500771b477cf from https://code.google.com/r/rsc-go13nacl. This CL does not include working NaCl support, there are probably two or three more large merges to come.
CL 15750044 is not included as it involves more invasive changes to the linker which will need to be merged separately.
The exact change lists included are
15050047: syscall: support for Native Client
15360044: syscall: unzip implementation for Native Client
15370044: syscall: Native Client SRPC implementation
15400047: cmd/dist, cmd/go, go/build, test: support for Native Client
15410048: runtime: support for Native Client
15410049: syscall: file descriptor table for Native Client
15410050: syscall: in-memory file system for Native Client
15440048: all: update +build lines for Native Client port
15540045: cmd/6g, cmd/8g, cmd/gc: support for Native Client
15570045: os: support for Native Client
15680044: crypto/..., hash/crc32, reflect, sync/atomic: support for amd64p32
15690044: net: support for Native Client
15690048: runtime: support for fake time like on Go Playground
15690051: build: disable various tests on Native Client
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/68150047
Currently an ECDHE handshake uses the client's curve preference. This
generally means that we use P-521. However, P-521's strength is
mismatched with the rest of the cipher suite in most cases and we have
a fast, constant-time implementation of P-256.
With this change, Go servers will use P-256 where the client supports
it although that can be overridden in the Config.
LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/66060043
crypto/tls has two functions for creating a client connection: Dial,
which most users are expected to use, and Client, which is the
lower-level API.
Dial does what you expect: it gives you a secure connection to the host
that you specify and the majority of users of crypto/tls appear to work
fine with it.
Client gives more control but needs more care. Specifically, if it
wasn't given a server name in the tls.Config then it didn't check that
the server's certificates match any hostname - because it doesn't have
one to check against. It was assumed that users of the low-level API
call VerifyHostname on the certificate themselves if they didn't supply
a hostname.
A review of the uses of Client both within Google and in a couple of
external libraries has shown that nearly all of them got this wrong.
Thus, this change enforces that either a ServerName or
InsecureSkipVerify is given. This does not affect tls.Dial.
See discussion at https://groups.google.com/d/msg/golang-nuts/4vnt7NdLvVU/b1SJ4u0ikb0J.
Fixes#7342.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/67010043
Users of the low-level, Client function are frequenctly missing the
fact that, unless they pass a ServerName to the TLS connection then it
cannot verify the certificates against any name.
This change makes it clear that at least one of InsecureSkipVerify and
ServerName should always be set.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/65440043
Callers of md5.Sum should do so to avoid allocations, the example did not demonstate this property.
««« original CL description
crypto/md5: add example for Sum
LGTM=dave
R=golang-codereviews, dave
CC=golang-codereviews
https://golang.org/cl/64820044
»»»
LGTM=minux.ma
R=r, minux.ma
CC=golang-codereviews
https://golang.org/cl/65180043
