* update to go1.21
Since the first minor version update has already been released, we can
probably feel comfortable updating to go1.21. This version now enforces
that the go version on the system is compatible with the version
specified in go.mod, so we can remove the old logic around checking the
minimum version in the Makefile.
- https://go.dev/doc/go1.21#tools
> To improve forwards compatibility, Go 1.21 now reads the go line in a go.work or go.mod file as a strict minimum requirement: go 1.21.0 means that the workspace or module cannot be used with Go 1.20 or with Go 1.21rc1. This allows projects that depend on fixes made in later versions of Go to ensure that they are not used with earlier versions. It also gives better error reporting for projects that make use of new Go features: when the problem is that a newer Go version is needed, that problem is reported clearly, instead of attempting to build the code and printing errors about unresolved imports or syntax errors.
* update to go1.22
* bump gvisor
* fix merge conflicts
* use latest gvisor `go` branch
Need to use the latest commit on the `go` branch, see:
- https://github.com/google/gvisor?tab=readme-ov-file#using-go-get
* mod tidy
* more fixes
* give smoketest more time
Is this why it is failing?
* also a little more sleep here
---------
Co-authored-by: Jack Doan <me@jackdoan.com>
Ensure that we don't break the build for mobile by doing a `go build`
for all of the non-main modules in the repo. Should hopefully catch
issues like #1035 sooner.
* add test for GOEXPERIMENT=boringcrypto
* fix NebulaCertificate.Sign
Set the PublicKey field in a more compatible way for the tests. The
current method grabs the public key from the certificate, but the
correct thing to do is to derive it from the private key. Either way
doesn't really matter as I don't think the Sign method actually even
uses the PublicKey field.
* assert boring
* cleanup tests
* Support NIST curve P256
This change adds support for NIST curve P256. When you use `nebula-cert ca`
or `nebula-cert keygen`, you can specify `-curve P256` to enable it. The
curve to use is based on the curve defined in your CA certificate.
Internally, we use ECDSA P256 to sign certificates, and ECDH P256 to do
Noise handshakes. P256 is not supported natively in Noise Protocol, so
we define `DHP256` in the `noiseutil` package to implement support for
it.
You cannot have a mixed network of Curve25519 and P256 certificates,
since the Noise protocol will only attempt to parse using the Curve
defined in the host's certificate.
* verify the curves match in VerifyPrivateKey
This would have failed anyways once we tried to actually use the bytes
in the private key, but its better to detect the issue up front with
a better error message.
* add cert.Curve argument to Sign method
* fix mismerge
* use crypto/ecdh
This is the preferred method for doing ECDH functions now, and also has
a boringcrypto specific codepath.
* remove other ecdh uses of crypto/elliptic
use crypto/ecdh instead
This adds a few build targets to compile with `GOEXPERIMENT=boringcrypto`:
- `bin-boringcrypto`
- `release-boringcrypto`
It also adds a field to the intial start up log indicating if
boringcrypto is enabled in the binary.
* build with go1.20
This has been out for a bit and is up to go1.20.4. We have been using
go1.20 for the Slack builds and have seen no issues.
* need the quotes
* use go install
These new helpers make the code a lot cleaner. I confirmed that the
simple helpers like `atomic.Int64` don't add any extra overhead as they
get inlined by the compiler. `atomic.Pointer` adds an extra method call
as it no longer gets inlined, but we aren't using these on the hot path
so it is probably okay.
This makes it easier to use the docker container smoke test that
GitHub actions runs. There is also `make smoke-docker-race` that runs the
smoke test with `-race` enabled.
This makes GOARM more generic and does GOMIPS in a similar way to
support mips-softfloat. We also set `-ldflags "-s -w"` for
mips-softfloat to give the best chance of the binary working on these
small devices.
Add support for freebsd. You have to set `tun.dev` in your config. The second pass of this would be to remove the exec calls and use ioctl(2) and route(4) instead, but we can do that in a second PR.
Co-authored-by: Wade Simmons <wade@wades.im>
This restores `make bin-windows` and also adds `make
build/nebula-windows-amd64.zip` to build the zip file.
Co-authored-by: Ryan Huber <rhuber@gmail.com>
This script will be triggered by any tag starting with `v[0-9]+.[0-9]+.[0-9]+` (i.e.
v1.1.0). It will create all of the .tar.gz files (or .zip for windows). The amd64 binaries will be
compiled on their target systems, the rest of the Linux architecures
will be cross compiled from the Linux amd64 host.
A SHASUM256.txt will also be generated and attached to the release.
Simplify the makefile by using implicit rules. The new structure for the
build directory when using `make all` or `make release` is:
build/$GOOS-$GOARCH-$GOARM/nebula
(The GOARM part is optional, and only used for linux-arm-6)
So, releases end up like `nebula-linux-amd64.tar.gz` or
`nebula-linux-arm-6.tar.gz`
This change also adds `-trimpath` to the build, to make the pathnames
more generic in our releases.
* Use golang.org/x/sys/unix for _linux.go sources
To support builds on GOARCH=386 and possibly elsewhere, it's necessary
to use the x/sys/unix package instead of the syscall package. This is
because the syscall package is frozen and does not support
SYS_GETSOCKNAME, SYS_RECVFROM, nor SYS_SENDTO for GOARCH=386.
This commit alone doesn't add support for 386 builds, just gets things
onto x/sys/unix so that it's possible.
The remaining uses of the syscall package relate to signals, which
cannot be switched to the x/sys/unix package at this time. Windows
support breaks, so they can either continue using the syscall package
(it's frozen, this is safe for Go 1.x at minimum), or something can be
written to just use both windows- and unix-compatible signals.
* Add linux-386, ppc64le targets to Makefile
Because 'linux' is linux-amd64 already, just add linux-386 and
linux-ppc64le targets to distinguish them. Would rename the linux
target but that might break existing uses.
Wade Simmons