Summary
The crypto/tls/generate_cert.go utility should only set the template
x509.Certificate's KeyUsage field to a value with the
x509.KeyUsageKeyEncipherment bits set when the certificate subject
public key is an RSA public key, not an ECDSA or ED25519 public key.
Background
RFC 5480 describes the usage of ECDSA elliptic curve subject keys with
X.509. Unfortunately while Section 3 "Key Usages Bits" indicates which
key usage bits MAY be used with a certificate that indicates
id-ecPublicKey in the SubjectPublicKeyInfo field it doesn't provide
guidance on which usages should *not* be included (e.g. the
keyEncipherment bit, which is particular to RSA key exchange). The same
problem is present in RFC 8410 Section 5 describing Key Usage Bits for
ED25519 elliptic curve subject keys.
There's an update to RFC 5480 in last call stage within the IETF LAMPS
WG, draft-ietf-lamps-5480-ku-clarifications-00. This update is meant
to clarify the allowed Key Usages extension values for certificates with
ECDSA subject public keys by adding:
> If the keyUsage extension is present in a certificate that indicates
> id-ecPublicKey as algorithm of AlgorithmIdentifier [RFC2986] in
> SubjectPublicKeyInfo, then following values MUST NOT be present:
>
> keyEncipherment; and
> dataEncipherment.
I don't believe there is an update for RFC 8410 in the works but I
suspect it will be clarified similarly in the future.
This commit updates generate_cert.go to ensure when the certificate
public key is ECDSA or ED25519 the generated certificate has the
x509.Certificate.KeyUsage field set to a value that doesn't include KUs
specific to RSA. For ECDSA keys this will adhere to the updated RFC 5480
language.
Fixes#36499
Change-Id: Ib1b0757c039b7fe97fc6d1e826fe6b88856c1964
GitHub-Last-Rev: a8f34fb33d
GitHub-Pull-Request: golang/go#36500
Reviewed-on: https://go-review.googlesource.com/c/go/+/214337
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This reverts https://golang.org/cl/191783.
Reason for revert: Broke too many programs which depended on the previous
behavior, even when it was the opposite of what the documentation said.
We can attempt to fix the original issue again for 1.16, while keeping
those programs in mind.
Fixes#39427.
Change-Id: I7a7f24b2a594c597ef625aeff04fff29aaa88fc6
Reviewed-on: https://go-review.googlesource.com/c/go/+/240657
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
On Linux, the linker uses fallocate to preallocate the output
file storage. The underlying file system may not support
fallocate, causing the test to fail. Skip the test in this case.
On darwin, apparently F_PREALLOCATE allocates from the end of the
allocation instead of the logical end of the file. Adjust the
size calculation.
Fixes#39905.
Change-Id: I01e676737fd2619ebbdba05c7cf7f424ec27de35
Reviewed-on: https://go-review.googlesource.com/c/go/+/240618
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When linking against a Go shared library, when a global variable
in the main module has a type defined in the shared library, the
linker needs to pull the GC data from the shared library to build
the GC program for the global variable. Currently, this fails
silently, as the shared library file is closed too early and the
read failed (with no error check), causing a zero GC map emitted
for the variable, which in turn causes the runtime to treat the
variable as pointerless.
For now, fix this by keeping the file open. In the future we may
want to use mmap to read from the shared library instead.
Also add error checking. And fix a (mostly harmless) mistake in
size caluculation.
Also remove an erroneous condition for ARM64. ARM64 used to have
a special case to get the addend from the relocation on the
gcdata field. That was removed, but the new code accidentally
returned 0 unconditionally. It's no longer necessary to have any
special case, since the addend is now applied directly to the
gcdata field on ARM64, like on all the other platforms.
Fixes#39927.
This is the second attempt of CL 240462. And this reverts
CL 240616.
Change-Id: I01c82422b9f67e872d833336885935bc509bc91b
Reviewed-on: https://go-review.googlesource.com/c/go/+/240621
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
The special symbols are linker-created symbols for special
purposes, therefore reachable (otherwise the linker won't create
them). Mark them so, so they get converted to sym.Symbols when we
convert to old symbol representation.
In particular, the failure for building shared library on PPC64
is due to .TOC. symbol not being converted to sym.Symbol, but
referenced in addmoduledata.
Change-Id: Iaf5d145ffa5d15122e86a6e6983514e56dd5d456
Reviewed-on: https://go-review.googlesource.com/c/go/+/240620
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Mention support for the 64-bit RISC-V instruction set (GOARCH=riscv64)
in the "Installing Go from source" document. Also sort the list of
supported instruction sets alphabetically.
Updates #27532
Change-Id: I07a443044a41a803853978dd7f7446de89ecceb5
Reviewed-on: https://go-review.googlesource.com/c/go/+/240377
Reviewed-by: Alberto Donizetti <alb.donizetti@gmail.com>
This reverts CL 240462.
Reason for revert: test fails on PPC64LE.
Updates #39927.
Change-Id: I4f14fd0c36e604a80ae9f2f86d1e643e28945e93
Reviewed-on: https://go-review.googlesource.com/c/go/+/240616
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
When linking against a Go shared library, when a global variable
in the main module has a type defined in the shared library, the
linker needs to pull the GC data from the shared library to build
the GC program for the global variable. Currently, this fails
silently, as the shared library file is closed too early and the
read failed (with no error check), causing a zero GC map emitted
for the variable, which in turn causes the runtime to treat the
variable as pointerless.
For now, fix this by keeping the file open. In the future we may
want to use mmap to read from the shared library instead.
Also add error checking. And fix a (mostly harmless) mistake in
size caluculation.
Also remove an erroneous condition for ARM64. ARM64 used to have
a special case to get the addend from the relocation on the
gcdata field. That was removed, but the new code accidentally
returned 0 unconditionally. It's no longer necessary to have any
special case, since the addend is now applied directly to the
gcdata field on ARM64, like on all the other platforms.
Fixes#39927.
Change-Id: Iecd32315b326c7059587fdc190e2fa99426e497e
Reviewed-on: https://go-review.googlesource.com/c/go/+/240462
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Also fix missing <code> tags in the other encoding/asn1 note.
Updates #37419
Change-Id: Ic0e9131016b44ed864629aa8d0a7fddb57146d21
Reviewed-on: https://go-review.googlesource.com/c/go/+/240518
Reviewed-by: Filippo Valsorda <filippo@golang.org>
We cannot use "0.0.0.0" (IPv4) or "::" (IPv6) for local address, so
don't use those addresses in the control message. Alternatively, we
could've used "*" instead.
Fixes#39931
Change-Id: Ib2dcbb1a0c648296c3ecaddbe938053a569b1f1b
Reviewed-on: https://go-review.googlesource.com/c/go/+/240464
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David du Colombier <0intro@gmail.com>
The sample code in 'Interfaces and methods' section contains a
data race. Handlers are served concurrently. The handler does write
and read operations; `go test -race` would fail (with concurrent
requests). Since the doc is frozen and the code remains less
cluttered without locks/atomic, don't change the sample code.
Change-Id: I654b324d2f0b7f48497822751907c7d39e2f0e3d
Reviewed-on: https://go-review.googlesource.com/c/go/+/239877
Reviewed-by: Rob Pike <r@golang.org>
The change is rolled back in CL 240179.
For #35151
For #39876
Change-Id: Id26ccbdb482772ac31c642156a9900102397b043
Reviewed-on: https://go-review.googlesource.com/c/go/+/240012
Reviewed-by: Alberto Donizetti <alb.donizetti@gmail.com>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
This reverts CL 203417.
Reason for revert: This change changes uses of tags like "XMLSchema-instance" without any recourse.
For #35151Fixes#39876
Change-Id: I4c85c8267a46b3748664b5078794dafffb42aa26
Reviewed-on: https://go-review.googlesource.com/c/go/+/240179
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Andrew Bonventre <andybons@golang.org>
This adds an alt tag for accessibility. The alt text is a visual
description of the text that is read out loud to users using a
screen reader. The HTML specifications indicate that alt tags for
decorative images should be left blank.
Fixes#39861
Change-Id: I76c39a461ceabe685826aa46e4f26ad893d50634
Reviewed-on: https://go-review.googlesource.com/c/go/+/240258
Reviewed-by: Alexander Nohe <alex.nohe427@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Make use of the extra parameter on "connect" control message to set the
local IP address and port. The ip(3) man page doesn't document that the
local IP address is settable, but upon inspection of the source code,
it's clearly settable.
Fixes#39747
Change-Id: Ied3d60452f20d6e5af23d1c1dcb34774af0dbd5b
Reviewed-on: https://go-review.googlesource.com/c/go/+/240064
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David du Colombier <0intro@gmail.com>
We were handling loopback devices when attempting to read hardware
address, but packet interfaces were not being handled. As a general fix,
don't attempt to read hardware address of any device that's not inside
/net.
Fixes#39908
Change-Id: Ifa05e270357e111c60906110db2cc23dc7c1c49c
Reviewed-on: https://go-review.googlesource.com/c/go/+/240259
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David du Colombier <0intro@gmail.com>
This constant does not make it into DWARF because it is an ideal
constant larger than maxint (1<<63-1). DWARF has no way to represent
signed values that large. Define a different typed constant that
is unsigned and so can represent this constant properly.
Viewcore needs this constant to interrogate the heap data structures.
In addition, the sign of arenaBaseOffset changed in 1.15, and providing
a new name lets viewcore detect the sign change easily.
Change-Id: I4274a2f6e79ebbf1411e85d64758fac1672fb96b
Reviewed-on: https://go-review.googlesource.com/c/go/+/240198
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
CL 230037 changed cmd/cgo to emit "type _Ctype_foo = bar" aliases for
all C.foo types mentioned in the original Go source files. However,
cmd/cgo already emits an appropriate type definition for _Ctype_void.
So if a source file explicitly mentions C.void, this resulted in
_Ctype_void being declared multiple times.
This CL fixes the issue by suppressing the "type _Ctype_void =
_Ctype_void" alias before printing it. This should be safe because
_Ctype_void is the only type that's specially emitted in out.go at the
moment.
A somewhat better fix might be to fix how _Ctype_void is declared in
the cmd/cgo "frontend", but this is a less invasive fix.
Fixes#39877.
Change-Id: Ief264b3847c8ef8df1478a6333647ff2cf09b63d
Reviewed-on: https://go-review.googlesource.com/c/go/+/240180
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Also crypto/tls.Config.BuildNameToCertificate.
Note that this field and method were deprecated in the Go 1.14 release,
so this change is to the 1.14 release notes.
Fixes#37626
Change-Id: If8549bc746f42a93f1903439e1b464b3e81e2c19
Reviewed-on: https://go-review.googlesource.com/c/go/+/240005
Reviewed-by: Filippo Valsorda <filippo@golang.org>
It doesn't have to. The type in the aux field is authoritative.
There are cases involving casting from interface{} where pointers
have a placeholder pointer type (because the type is not known when
the IData op is generated).
The check was introduced in CL 13447.
Fixes#39459
Change-Id: Id77a57577806a271aeebd20bea5d92d08ee7aa6b
Reviewed-on: https://go-review.googlesource.com/c/go/+/239817
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
File.Sync was returning *SyscallError instead of *PathError on Plan 9.
Adjust the error type to match other systems.
Fixes#39800
Change-Id: I844e716eb61c193ef78d29cb0b4a3ef790bb3320
Reviewed-on: https://go-review.googlesource.com/c/go/+/239857
Reviewed-by: David du Colombier <0intro@gmail.com>
Now that we've added a os.File.ReadFrom method, io.CopyBuffer to a
os.File will no longer use the provided buffer.
For #16474
For #36817
For #37419
Change-Id: I79a3bf778ff93eab88e88dd9ecbb8c7ea101e868
Reviewed-on: https://go-review.googlesource.com/c/go/+/238864
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
After CL 228645 some mentions of the Deadline methods referred
to the Timeout method, and some to os.ErrDeadlineExceeded.
Stop referring to the Timeout method, to encourage ErrDeadlineExceeded.
For #31449
Change-Id: I27b8ff34f31798f38b06437546886af8cce98ca4
Reviewed-on: https://go-review.googlesource.com/c/go/+/239705
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Switched the generator to using the open source releases of the root
store rather than HTML parsing, while trying to emulate the sorting
algorithm of the table to reduce churn.
Updates #38843
Change-Id: I78608d245eabc2a35c2f98635ed5f1a531ad2ba8
Reviewed-on: https://go-review.googlesource.com/c/go/+/239557
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Normally, packages are loaded in dependency order, and if a
Library object is not nil, it is already loaded with the actual
fingerprint. In shared build mode, however, packages may be added
not in dependency order (e.g. go install -buildmode=shared std
adds all std packages before loading them), and it is possible
that a Library's fingerprint is not yet loaded. Skip the check
in this case (when the fingerprint is the zero value).
Fixes#39777.
Change-Id: I66208e92bf687c8778963ba8e33e9bd948f82f3a
Reviewed-on: https://go-review.googlesource.com/c/go/+/239517
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Follow glibc's implementation and check secondary group memberships
using Getgroups.
No test since we cannot easily change file permissions when not running
as root and the test is meaningless if running as root.
Same as CL 238722 did for x/sys/unix
Updates #39660
Change-Id: I6af50e27b255e33405558947a0ab3dfbc33b2d50
Reviewed-on: https://go-review.googlesource.com/c/go/+/238937
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
addpersrc is called very late, after we have converted to
sym.Symbols and various fields in loader representation have been
dropped. Use the Symbol representation there.
Fixes#39658.
Change-Id: I616e838655b6f01554644171317e2cc5cefabf39
Reviewed-on: https://go-review.googlesource.com/c/go/+/238779
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
The preceding paragraph suggests the test run will produce a file called trace.out.
The same name, trace.out, is used in the output from go help testflag, thus we change the go test line instead of changing the preceding paragraph.
Change-Id: Ib1fa7e49e540853e263a2399b16040ea6f41b703
GitHub-Last-Rev: 3535e62bf8
GitHub-Pull-Request: golang/go#39709
Reviewed-on: https://go-review.googlesource.com/c/go/+/238997
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
In os.Getenv and os.Setenv, instead of directly reading and writing the
Plan 9 environment device (which may be shared with other processes),
use a local copy of environment variables cached at the start of
execution. This gives the same semantics for Getenv and Setenv as on
other operating systems which don't share the environment, making it
more likely that Go programs (for example the build tests) will be
portable to Plan 9.
This doesn't preclude writing non-portable Plan 9 Go programs which make
use of the shared environment semantics (for example to have a command
which exports variable definitions to the parent shell). To do this, use
ioutil.ReadFile("/env/"+key) and
ioutil.WriteFile("/env/"+key, value, 0666)
in place of os.Getenv(key) and os.Setenv(key, value) respectively.
Note that CL 5599054 previously added env cacheing, citing efficiency
as the reason. However it made the cache write-through, with Setenv
changing the shared environment as well as the cache (so not consistent
with Posix semantics), and Clearenv breaking the sharing of the
environment between the calling thread and other threads (leading to
unpredictable behaviour). Because of these inconsistencies (#8849),
CL 158970045 removed the cacheing again.
This CL restores cacheing but without write-through. The local cache is
initialised at start of execution, manipulated by the standard functions
in syscall/env_unix.go to ensure the same semantics, and exported only
when exec'ing a new program.
Fixes#34971Fixes#25234Fixes#19388
Updates #38772
Change-Id: I2dd15516d27414afaf99ea382f0e00be37a570c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/236520
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Fazlul Shahriar <fshahriar@gmail.com>
Reviewed-by: David du Colombier <0intro@gmail.com>
reflect.assignTo writes to the target using write barriers. Make sure
that the memory it is writing to is zeroed, so the write barrier does
not read pointers from uninitialized memory.
Fixes#39541
Change-Id: Ia64b2cacc193bffd0c1396bbce1dfb8182d4905b
Reviewed-on: https://go-review.googlesource.com/c/go/+/238760
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Fixes the *noov opcodes so they handle a constant argument properly.
Most of the infrastructure for this CL is in CL 238077 (the arm32 one).
Fixes#39505
Change-Id: Id424a4e18964b848f05aa42f4d78e5f2e2cdf43b
Reviewed-on: https://go-review.googlesource.com/c/go/+/237999
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Encode the flag results in an auxint field instead of having
one opcode per flag state. This helps us handle the new *noov
branches in a unified manner.
This is only for arm, arm64 is in a subsequent CL.
We could extend to other architectures as well, athough it would
only be cleanup, no behavioral change.
Update #39505
Change-Id: Ia46cea596faad540d1496c5915ab1274571543f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/238077
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
