1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
|
# 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](https://hub.docker.com/r/goboring/golang/))
and should need no other modifications.
## Building from Bazel
Starting from [bazelbuild/rules_go](https://github.com/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`:
```python
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](https://godoc.org/rsc.io/goversion) will report the
crypto implementation used by a given binary when invoked with the `-crypto` flag.
|
