1
0
mirror of https://github.com/golang/go synced 2024-11-17 10:04:43 -07:00
go/misc/boring
Filippo Valsorda 347af7f060 [dev.boringcrypto] misc/boring: add go1.12.1b4 and update build scripts
The inliner seems to have gotten a bit too smart in 1.12 and it made
sha1.boringNewSHA1 disappear. Replace it with the proper
crypto/internal/boring/sig.BoringCrypto signature. Also, switch the
negative signature to sha256.(*digest), since SHA-256 is used for sure
by cmd/go. Not using crypto/internal/boring/sig.StandardCrypto just to
be safe, in case the crypto/internal/boring/sig mechanism breaks.

Also, had to fight #30833 and #30515 to get
golang.org/x/build/cmd/release to build in modules mode.

Change-Id: I46f1471582fd77daae47d00baab975109902052d
Reviewed-on: https://go-review.googlesource.com/c/go/+/169517
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
2019-03-28 18:21:20 +00:00
..
build.docker [dev.boringcrypto] misc/boring: add go1.12.1b4 and update build scripts 2019-03-28 18:21:20 +00:00
build.release [dev.boringcrypto] misc/boring: add go1.12.1b4 and update build scripts 2019-03-28 18:21:20 +00:00
dockerfile.in
go-wrapper
README.md [dev.boringcrypto] misc/boring: add go1.10.4b4 and go1.11b4 releases 2018-10-01 21:36:07 +00:00
RELEASES [dev.boringcrypto] misc/boring: add go1.12.1b4 and update build scripts 2019-03-28 18:21:20 +00:00
VERSION

README.md

This directory holds build scripts for unofficial, unsupported distributions of Go+BoringCrypto.

Version strings

The distribution name for a Go+BoringCrypto release has the form <GoVersion>b<BoringCryptoVersion>, where <GoVersion> is the Go version the release is based on, and <BoringCryptoVersion> is an integer that increments each time there is a new release with different BoringCrypto bits. The <BoringCryptoVersion> is stored in the VERSION file in this directory.

For example, the first release is based on Go 1.8.3 is go1.8.3b1. If the BoringCrypto bits are updated, the next would be go1.8.3b2. If, after that, Go 1.9 is released and the same BoringCrypto code added to it, that would result in go1.9b2. There would likely not be a go1.9b1, since that would indicate Go 1.9 with the older BoringCrypto code.

Releases

The build.release script prepares a binary release and publishes it in Google Cloud Storage at gs://go-boringcrypto/, making it available for download at https://go-boringcrypto.storage.googleapis.com/<FILE>. The script records each published release in the RELEASES file in this directory.

The build.docker script, which must be run after build.release, prepares a Docker image and publishes it on hub.docker.com in the goboring organization. go1.8.3b1 is published as goboring/golang:1.8.3b1.

Release process

Development is done on the dev.boringcrypto branch, which tracks master. Releases are cut from dev.boringcrypto.go1.X branches, which are BoringCrypto backported to the Go 1.X release branches. To issue new BoringCrypto releases based on Go 1.X:

  1. If the BoringCrypto bits have been updated, increment the number in VERSION, send that change out as a CL for review, get it committed to dev.boringcrypto, and run git sync.

  2. Change to the dev.boringcrypto.go1.X branch and cherry-pick all BoringCrypto updates, including the update of the VERSION file. If desired, merge release-branch.go1.X into dev.boringcrypto.go1.X. Mail them out and get them committed.

  3. Back on the dev.boringcrypto branch, run git fetch, make.bash and then build.release dev.boringcrypto.go1.X. The script will determine the base Go version and the BoringCrypto version, build a release, and upload it.

  4. Run build.docker, which will build and upload a Docker image from the latest release.

  5. Send out a CL with the updated RELEASES file and get it committed to dev.boringcrypto.

Building from Docker

A Dockerfile that starts with FROM golang:1.8.3 can switch to FROM goboring/golang:1.8.3b2 (see goboring/golang on Docker Hub) and should need no other modifications.

Building from Bazel

Starting from bazelbuild/rules_go tag 0.7.1, simply download the BoringCrypto-enabled Go SDK using go_download_sdk() before calling go_register_toolchains().

For example, to use Go 1.9.3 with BoringCrypto on Linux, use the following lines in WORKSPACE:

load("@io_bazel_rules_go//go:def.bzl", "go_rules_dependencies", "go_download_sdk", "go_register_toolchains")

go_rules_dependencies()

go_download_sdk(
    name = "go_sdk",
    sdks = {
       "linux_amd64": ("go1.9.3b4.linux-amd64.tar.gz", "db1997b2454a2f27669b849d2d2cafb247a55128d53da678f06cb409310d6660"),
    },
    urls = ["https://storage.googleapis.com/go-boringcrypto/{}"],
)

go_register_toolchains()

Note: you must not enable pure mode, since cgo must be enabled. To ensure that binaries are linked with BoringCrypto, you can set pure = "off" on all relevant go_binary rules.

Caveat

BoringCrypto is used for a given build only in limited circumstances:

  • The build must be GOOS=linux, GOARCH=amd64.
  • The build must have cgo enabled.
  • The android build tag must not be specified.
  • The cmd_go_bootstrap build tag must not be specified.

The version string reported by runtime.Version does not indicate that BoringCrypto was actually used for the build. For example, linux/386 and non-cgo linux/amd64 binaries will report a version of go1.8.3b2 but not be using BoringCrypto.

To check whether a given binary is using BoringCrypto, run go tool nm on it and check that it has symbols named *_Cfunc__goboringcrypto_*.

The program rsc.io/goversion will report the crypto implementation used by a given binary when invoked with the -crypto flag.