mirror of https://github.com/golang/go.git
1dcb5836ad
Both gcc and clang accept an option -fplugin=code.so to load a plugin from the ELF shared object file code.so. Obviously that plugin can then do anything it wants during the build. This is contrary to the goal of "go get" never running untrusted code during the build. (What happens if you choose to run the result of the build is your responsibility.) Disallow this behavior by only allowing a small set of known command-line flags in #cgo CFLAGS directives (and #cgo LDFLAGS, etc). The new restrictions can be adjusted by the environment variables CGO_CFLAGS_ALLOW, CGO_CFLAGS_DISALLOW, and so on. See the documentation. In addition to excluding cgo-defined flags, we also have to make sure that when we pass file names on the command line, they don't look like flags. So we now refuse to build packages containing suspicious file names like -x.go. A wrinkle in all this is that GNU binutils uniformly accept @foo on the command line to mean "if the file foo exists, then substitute its contents for @foo in the command line". So we must also reject @x.go, flags and flag arguments beginning with @, and so on. Fixes #23672, CVE-2018-6574. Change-Id: I59e7c1355155c335a5c5ae0d2cf8fa7aa313940a Reviewed-on: https://team-review.git.corp.google.com/209949 Reviewed-by: Ian Lance Taylor <iant@google.com> |
||
|---|---|---|
| .. | ||
| README | ||
| build.go | ||
| buildgo.go | ||
| buildruntime.go | ||
| buildtool.go | ||
| cpuid_386.s | ||
| cpuid_amd64.s | ||
| cpuid_default.s | ||
| doc.go | ||
| imports.go | ||
| main.go | ||
| sys_default.go | ||
| sys_windows.go | ||
| test.go | ||
| test_linux.go | ||
| util.go | ||
| util_gc.go | ||
| util_gccgo.go | ||
| vfp_arm.s | ||
| vfp_default.s | ||
README
This program, dist, is the bootstrapping tool for the Go distribution. As of Go 1.5, dist and other parts of the compiler toolchain are written in Go, making bootstrapping a little more involved than in the past. The approach is to build the current release of Go with an earlier one. The process to install Go 1.x, for x ≥ 5, is: 1. Build cmd/dist with Go 1.4. 2. Using dist, build Go 1.x compiler toolchain with Go 1.4. 3. Using dist, rebuild Go 1.x compiler toolchain with itself. 4. Using dist, build Go 1.x cmd/go (as go_bootstrap) with Go 1.x compiler toolchain. 5. Using go_bootstrap, build the remaining Go 1.x standard library and commands. NOTE: During the transition from the old C-based toolchain to the Go-based one, step 2 also builds the parts of the toolchain written in C, and step 3 does not recompile those. Because of backward compatibility, although the steps above say Go 1.4, in practice any release ≥ Go 1.4 but < Go 1.x will work as the bootstrap base. See golang.org/s/go15bootstrap for more details. Compared to Go 1.4 and earlier, dist will also take over much of what used to be done by make.bash/make.bat/make.rc and all of what used to be done by run.bash/run.bat/run.rc, because it is nicer to implement that logic in Go than in three different scripting languages simultaneously.