When building for an ARMv8 in 32-bit, Go does not yet support ARMv8
optimizations (see issue: https://github.com/golang/go/issues/29373)
but can still benefit from ARMv7 optimizations.
Signed-off-by: Michael Baudino <michael@baudi.no>
[yann.morin.1998@free.fr:
- move the comment to its own line, expand and reword it a bit
- reword the commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This commit fixes a typo in variable names that caused CC and CXX
environment variables to be empty.
Signed-off-by: Michael Baudino <michael@baudi.no>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
go1.15.6 (released 2020/12/03) includes fixes to the compiler, linker, runtime,
the go command, and the io package.
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security issues:
- math/big: panic during recursive division of very large numbers
A number of math/big.Int methods (Div, Exp, DivMod, Quo, Rem, QuoRem, Mod,
ModInverse, ModSqrt, Jacobi, and GCD) can panic when provided crafted
large inputs. For the panic to happen, the divisor or modulo argument
must be larger than 3168 bits (on 32-bit architectures) or 6336 bits (on
64-bit architectures). Multiple math/big.Rat methods are similarly affected.
crypto/rsa.VerifyPSS, crypto/rsa.VerifyPKCS1v15, and crypto/dsa.Verify may
panic when provided crafted public keys and signatures. crypto/ecdsa and
crypto/elliptic operations may only be affected if custom CurveParams with
unusually large field sizes (several times larger than the largest
supported curve, P-521) are in use. Using crypto/x509.Verify on a crafted
X.509 certificate chain can lead to a panic, even if the certificates
don’t chain to a trusted root. The chain can be delivered via a
crypto/tls connection to a client, or to a server that accepts and
verifies client certificates. net/http clients can be made to crash by an
HTTPS server, while net/http servers that accept client certificates will
recover the panic and are unaffected.
Moreover, an application might crash invoking
crypto/x509.(*CertificateRequest).CheckSignature on an X.509 certificate
request or during a golang.org/x/crypto/otr conversation. Parsing a
golang.org/x/crypto/openpgp Entity or verifying a signature may crash.
Finally, a golang.org/x/crypto/ssh client can panic due to a malformed
host key, while a server could panic if either PublicKeyCallback accepts a
malformed public key, or if IsUserAuthority accepts a certificate with a
malformed public key.
Thanks to the Go Ethereum team and the OSS-Fuzz project for reporting
this. Thanks to Rémy Oudompheng and Robert Griesemer for their help
developing and validating the fix.
This issue is CVE-2020-28362 and Go issue golang.org/issue/42552.
- cmd/go: arbitrary code execution at build time through cgo
The go command may execute arbitrary code at build time when cgo is in
use. This may occur when running go get on a malicious package, or any
other command that builds untrusted code.
This can be caused by malicious gcc flags specified via a #cgo directive,
or by a malicious symbol name in a linked object file.
Thanks to Imre Rad and to Chris Brown and Tempus Ex respectively for
reporting these issues.
These issues are CVE-2020-28367 and CVE-2020-28366, and Go issues
golang.org/issue/42556 and golang.org/issue/42559 respectively.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Bugfix release. From the release notes:
go1.15.4 (released 2020/11/05) includes fixes to cgo, the compiler, linker,
runtime, and the compress/flate, net/http, reflect, and time packages.
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
go1.15.3 (released 2020/10/14) includes fixes to cgo, the compiler, runtime, the
go command, and the bytes, plugin, and testing packages.
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
go1.15.2 (released 2020/09/09) includes fixes to the compiler, runtime,
documentation, the go command, and the net/mail, os, sync, and testing packages.
https://golang.org/doc/devel/release.html#go1.15
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Go 1.14, 1.15 are major releases of Go.
Read the Release Notes for more information:
- https://golang.org/doc/go1.14
- https://golang.org/doc/go1.15
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The Go compiler needs to know the "import path" to the root of package
source repositories. Previously, this was done by creating a fake
_gopath in the build directory and symlinking the package source into
that path.
Go has deprecated the GOPATH mechanism in favor of a new approach -
Modules - which specifies the root import path (and dependencies) in a
"go.mod" file. This commit moves Buildroot to use the new go.mod
approach, which requires:
- Passing GO111MODULE=on when building host or target Go packages.
- Passing GOPROXY=off and -mod=vendor to prevent the Go module system
from downloading by itself sources from the Internet. We currently
only support Go packages that have all their dependencies in their
source tree in "vendor" directories.
- Specifying a <pkg>_GOMOD variable, which is used both to create a
minimal go.mod file in the package source tree if it exists, and to
invoke the right build targets. Indeed, all elements in
<pkg>_BUILD_TARGETS are now relative to <pkg>_GOMOD.
Reference: https://github.com/golang/go/wiki/Modules
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
There is no point in having some common Go env variables defined in
pkg-golang.mk:GO_COMMON_ENV, and some in
package/go/go.mk:HOST_GO_COMMON_ENV. Let's move all of them to
package/go/go.mk:HOST_GO_COMMON_ENV.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
HOST_GO_HOST_ENV is explicitly specifying
HOST_CGO_{CFLAGS,CXXFLAGS,LDFLAGS}, so let's do the same for target
packages.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
A few variables are common between HOST_GO_TARGET_ENV and
HOST_GO_HOST_ENV, so let's introduce a HOST_GO_COMMON_ENV variable for
those few common ones (which will increase in follow-up commits).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
package/go/go.mk provides a HOST_GO_TARGET_ENV which provides a useful
set of environment variables needed to build target Go packages.
For host packages, we simply have package/pkg-golang.mk defining
GO_HOST_ENV to specify CFLAGS/LDFLAGS, but that's it: we don't pass an
explicit path to the compiler, we don't pass GO111MODULE, GOCACHE,
GOROOT, etc.
This commit introduces a HOST_GO_HOST_ENV variable that provides the
appropriate set of environment variables to use when building host
golang packages.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
go1.13.14 (released 2020/07/16) includes fixes to the compiler, vet, and
the database/sql, net/http, and reflect packages.
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
go1.13.13 (released 2020/07/14) includes security fixes to the
crypto/x509 and net/http packages.
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
go1.13.9 (released 2020/03/19) includes fixes to the go command, tools, the
runtime, the toolchain, and the crypto/cypher package.
go1.13.10 (released 2020/04/08) includes fixes to the go command, the runtime,
and the os/exec and time packages.
go1.13.11 (released 2020/05/14) includes fixes to the compiler.
go1.13.12 (released 2020/06/01) includes fixes to the runtime, and the go/types
and math/big packages.
Release notes: https://golang.org/doc/go1.13
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security issue:
- Panic in crypto/x509 certificate parsing and golang.org/x/crypto/cryptobyte
On 32-bit architectures, a malformed input to crypto/x509 or the ASN.1
parsing functions of golang.org/x/crypto/cryptobyte can lead to a panic.
The malformed certificate can be delivered via a crypto/tls connection to a
client, or to a server that accepts client certificates. net/http clients
can be made to crash by an HTTPS server, while net/http servers that accept
client certificates will recover the panic and are unaffected. Thanks to
Project Wycheproof for providing the test cases that led to the discovery of
this issue. The issue is CVE-2020-7919 and Go issue golang.org/issue/36837.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
go1.13.6 (released 2020/01/09) includes fixes to the runtime and the net/http
package.
https://github.com/golang/go/issues?q=milestone=Go1.13.6
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
go1.13.5 (released 2019/12/04) includes fixes to the go command, the runtime,
the linker, and the net/http package.
https://github.com/golang/go/issues?q=milestone%3AGo1.13.5
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
go1.13.4 (released 2019/10/31) with fixes to the net/http and syscall packages.
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security issues (1.33.2):
- CVE-2019-17596: Invalid DSA public keys can cause a panic in dsa.Verify.
In particular, using crypto/x509.Verify on a crafted X.509 certificate
chain can lead to a panic, even if the certificates don’t chain to a
trusted root. The chain can be delivered via a crypto/tls connection to a
client, or to a server that accepts and verifies client certificates.
net/http clients can be made to crash by an HTTPS server, while net/http
servers that accept client certificates will recover the panic and are
unaffected.
Additionally, 1.13.3 fixes a number of issues. From the release notes:
Fixes to the go command, the toolchain, the runtime, syscall, net, net/http,
and crypto/ecdsa packages
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security vulnerabilities:
- CVE-2019-16276: Go before 1.12.10 and 1.13.x before 1.13.1 allow HTTP
Request Smuggling.
https://github.com/golang/go/issues/34540
>From the release notes:
go1.12.10 (released 2019/09/25) includes security fixes to the net/http and
net/textproto packages
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
For post-1.12.8 fixes. From the release notes:
go1.12.9 (released 2019/08/15) includes fixes to the linker, and the os and
math/big packages.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
go1.12.6 (released 2019/06/11) includes fixes to the compiler, the linker, the
go command, and the crypto/x509, net/http, and os packages.
go1.12.7 (released 2019/07/08) includes fixes to cgo, the compiler, and the
linker.
go1.12.8 (released 2019/08/13) includes security fixes to the net/http and
net/url packages.
https://golang.org/doc/devel/release.html
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Fixes a number of issues discovered since 1.12.4. From the release notes:
go1.12.5 (released 2019/05/06) includes fixes to the compiler, the linker,
the go command, the runtime, and the os package.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes a number of issues discovered since 1.12.1. From the release notes:
go1.12.2 (released 2019/04/05) includes fixes to the compiler, the go
command, the runtime, and the doc, net, net/http/httputil, and os packages.
See the Go 1.12.2 milestone on our issue tracker for details.
go1.12.3 (released 2019/04/08) was accidentally released without its
intended fix. It is identical to go1.12.2, except for its version number.
The intended fix is in go1.12.4.
go1.12.4 (released 2019/04/11) fixes an issue where using the prebuilt
binary releases on older versions of GNU/Linux led to failures when linking
programs that used cgo. Only Linux users who hit this issue need to update.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The go toolchain can cross-compile by default. So most of the time,
building a toolchain that supports a target, allows us to also build go
binaries for the host. This is how support for host go packages was
added: we use the same toolchain that was initially built only for
target.
But we might want to build a go binary for the host, when compiling a
target for which go isn't supported. Then, building host-go will fail:
by default, we build go for a specific target, and give the toolchain
bootstrap scripts the cross compiler we'll use.
This change modifies this behaviour: we only assume the go toolchain is
cross-capable if we know the current target is supported. Otherwise this
is a simple host go tool. We don't need to set any of the options needed
for cross-compilation in that case.
Thus, only set all the target-specific go options under a condition that
the target arch is supported. The only option we still set is
HOST_GO_CGO_ENABLED, and we always set it to enabled.
It was also considered to create a separate package to build the
go-for-host compiler which would be used for host-go-packages, but that
would lead to a lot of duplication and is completely unnecessary.
Fixes:
http://autobuild.buildroot.net/results/98b9c7aaff2af4d19adfedac00b768d92530ce94http://autobuild.buildroot.net/results/bed228995ce3778720f991df9b41345a7c724a46http://autobuild.buildroot.net/results/3b3ea148165b96513ea511ee0d4adb334a6afac8
Signed-off-by: Anisse Astier <anisse@astier.eu>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Anisse Astier <anisse@astier.eu>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
With this you can add:
$(eval $(host-golang-package))
to a package .mk file to build for host.
Signed-off-by: Mirza Krak <mirza.krak@northern.tech>
Acked-by: Angelo Compagnucci <angelo@amarulasolutions.com>
Tested-by: Angelo Compagnucci <angelo@amarulasolutions.com>
Signed-off-by: Angelo Compagnucci <angelo@amarulasolutions.com>
Tested-by: Adam Duskett <aduskett@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The hidden Config.in option BR2_PACKAGE_HOST_GO_ARCH_SUPPORTS name is
not very clear as to whether it says whether Go is available for the
target architecture or the host architecture.
Until now, this was fine since there was support for host Go
packages. But as we are about to introduce support for building host
Go packages, we need to clarify the meaning of
BR2_PACKAGE_HOST_GO_ARCH_SUPPORTS. Since it says whether the target
architecture has support for Go or not, we rename it to
BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS.
And since BR2_PACKAGE_HOST_GO_CGO_LINKING_SUPPORTS is tightly related,
we rename it to BR2_PACKAGE_HOST_GO_TARGET_CGO_LINKING_SUPPORTS.
Signed-off-by: Angelo Compagnucci <angelo@amarulasolutions.com>
Tested-by: Adam Duskett <aduskett@gmail.com>
[Thomas: entirely rewrite commit log]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Go 1.12 was released on 2/25/2019: https://blog.golang.org/go1.12
Go 1.12.1 was released on 3/14/2019:
https://golang.org/doc/devel/release.html#go1.12.minor
Additional notes on how Go modules will evolve in 2019 are here:
https://blog.golang.org/modules2019
In Go 1.12, module support remains the same as in Go 1.11. GOPATH is scheduled
for deprecation in 1.13, however. The Buildroot Go package infrastructure should
therefore aim to migrate to a new, currently undefined, Go module friendly
compilation approach before Go 1.13 is released.
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Set the GOCACHE environment variable properly.
It was previously unset, and defaults to $HOME/.cache/go-build.
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Go "modules" refers to the dependency fetching, verification (hashing), and
version control system built into Go as of 1.11.
It is not desirable to have Go modules enabled in Buildroot in the normal case,
as Buildroot manages downloading the sources, and third party dependency
managers are typically not used.
In the absence of the GO111MODULE environment variable, the Go compiler will
correctly compile using the "vendor" version of dependencies downloaded by
Buildroot during the compilation process for Go-based packages.
However, if the user sets the GO111MODULE=on environment variable, the Go
compiler will download the Go dependencies for Buildroot packages, using the
modules system. This is potentially unintended behavior from user environment
variables.
This commit sets the GO111MODULE=off variable in the Go target and host
compilation environments, disabling Go modules support for Buildroot mainline
packages.
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Go 1.11.5 addresses a reported security issue, CVE-2019-6486.
Signed-off-by: Christian Stewart <christian@paral.in>
Acked-by: Anisse Astier <anisse@astier.eu>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
go 1.11.3 fixes the following security issues:
cmd/go: remote command execution during "go get -u"
The issue is CVE-2018-16873 and Go issue golang.org/issue/29230. See the Go issue for details.
Thanks to Etienne Stalmans from the Heroku platform security team for discovering and reporting this issue.
cmd/go: directory traversal in "go get" via curly braces in import paths
The issue is CVE-2018-16874 and Go issue golang.org/issue/29231. See the Go issue for details.
Thanks to ztz of Tencent Security Platform for discovering and reporting this issue.
crypto/x509: CPU denial of service in chain validation
The issue is CVE-2018-16875 and Go issue golang.org/issue/29233. See the Go issue for details.
Thanks to Netflix for discovering and reporting this issue.
go 1.11.4 fixes issues, including regressions introduced by 1.11.3:
1.11.4 includes fixes to cgo, the compiler, linker, runtime, documentation, go
command, and the net/http and go/types packages. It includes a fix to a bug
introduced in Go 1.11.3 that broke go get for import path patterns
containing "...".
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Bumps Golang host-go compiler to 1.11.2 release.
Add hash for LICENSE.
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Bumps Golang host-go compiler to 1.11.1 release.
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This bump contains many bug fixes, as well as the following security
issue, patched in Go 1.10.1:
CVE-2018-7187: The "go get" implementation in Go 1.9.4, when the
-insecure command-line option is used, does not validate the import path
(get/vcs.go only checks for "://" anywhere in the string), which allows
remote attackers to execute arbitrary OS commands via a crafted web
site.
Signed-off-by: Anisse Astier <anisse@astier.eu>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Now that we fixed cross-compilation in the go package, cleanup the build
to remove the workaround added in 60c5c96ae1
"package/go: Build host tools with host CC". We only need a single pass
to build the go toolchain.
Signed-off-by: Anisse Astier <anisse@astier.eu>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This commit bumps the Go programming language to the 1.10 release.
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
go-bootstrap is a host package that builds a first stage Go compiler,
later used to build the final Go compiler. However, this first stage
compiler only supports building on x86, x86-64 and arm as host
architectures, so we need to add the relevant architecture
dependencies to avoid having go-bootstrap built on other unsupported
platforms.
We do this by introducing BR2_PACKAGE_HOST_GO_BOOTSTRAP_ARCH_SUPPORTS
in a new package/go-bootstrap/Config.in.host file. This option is then
used by BR2_PACKAGE_HOST_GO_ARCH_SUPPORTS to make sure we can't enable
Go packages when the host architecture doesn't allow building the Go
compiler.
Fixes:
http://autobuild.buildroot.net/results/cbd419c6ab6fa8a6d18dc137c91f895867e53b8a/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
