wireguard-tools ships wg and wg-quick with almost no build dependencies

Two utilities, one for configuration and one for convenience

wireguard-tools supplies the main userspace tooling for using and configuring WireGuard tunnels, and the two utilities have different jobs. wg is the one that matters, and it is the direct interface to the tunnel configuration on the system. wg-quick is described in the documentation as a very quick and dirty bash script for reading a few extra variables from wg style configuration files and automatically configuring the interface. The distinction is a design opinion, and the documentation is unusually candid about it. If you already have a working network management tool or configuration, the advice is that you probably want to integrate wg or the direct WireGuard API into your network manager rather than using wg-quick, while for people who like simple quick and dirty scripts it is nice. The project supports Linux, OpenBSD, FreeBSD, macOS, Windows and Android, and further information is at the WireGuard site rather than in the repository, which is a mirror.

A build with no dependencies at all

The build section is short because there is almost nothing to it:

$ cd src
$ make

The documentation states there are no dependencies other than a good C compiler and a sane libc. For a networking tool that ships on every Linux distribution, on the BSDs, on macOS and on Windows, that is a significant property, since a build with no third party libraries is a build that will not break when a library changes underneath it. The repository mirrors on GitHub are described as mirror only, with the official repository at git.zx2c4.com, and the top level here holds just a COPYING file, a README, an src/ directory and a contrib/ directory. The primary language is C and the licence is GPLv2, which for a tool that is usually invoked as root on a machine is worth a thought, since linking it into proprietary software carries obligations.

The install switches decide what lands on the system

The installation is a single make install, but the environment variables around it are where the real decisions live, and the documentation says the second section of them is the one that is not standard. The standard group sets paths, with PREFIX defaulting to /usr, DESTDIR empty, BINDIR at $(PREFIX)/bin, LIBDIR at $(PREFIX)/lib, MANDIR at $(PREFIX)/share/man, BASHCOMPDIR at $(PREFIX)/share/bash-completion/completions, RUNSTATEDIR at /var/run and PKG_CONFIG at pkg-config. The switches are WITH_BASHCOMPLETION, WITH_WGQUICK, WITH_SYSTEMDUNITS and DEBUG, and each defaults to auto-detect. Bash completion is described as just a nice thing for people who have bash, so set it to no if you do not, and to yes to force it even when bash-completion is not detected in DESTDIR. WITH_SYSTEMDUNITS decides whether systemd units for wg-quick are installed, and if you do not use systemd you certainly do not want this, so set it to no. DEBUG builds with -g when set to yes. The advice for a simple make and make install user is to rely on auto-detection, but for someone writing a distro package the documentation says to set these explicitly.

A simple user, a specific install

There is one thing in the documentation worth reading twice, because it is the difference between a working install and a broken one. The first section is rather standard, and the second section is not, and the reason is that the three switches decide whether you end up with a bash script that assumes bash, systemd unit files that assume systemd, and a completion set that assumes bash-completion. The auto-detection can be wrong in both directions. A distribution build that happens to detect a bash-completion directory during packaging will ship completion files whether or not the package wants them, and a system where systemd is present in the build container but absent at runtime will get unit files that fail. The documentation is explicit that forcing is possible in both directions, with yes to install regardless of detection and no to skip. For a distribution maintainer, the practical advice is to set all three switches explicitly rather than trusting detection, because a package that silently gains or loses a dependency between build environments is a class of bug that is annoying to track down.

The contrib directory is examples, not production code

The contrib/ subdirectory contains various scripts and examples, and the documentation says most of these are not immediately useful for production use but should provide inspiration for creating fully-featured tools, with a README in each directory to explain what is there. The distinction is worth keeping in mind when you find something useful in there. These are demonstrations of how one might script against WireGuard, not a supported tool set with a compatibility promise, and copying one into your own infrastructure means owning it. The main source tree is the opposite, since wg and wg-quick are the supported entry points and carry the licence and maintenance of the project. The overall shape of the repository is then clear. A small, dependency-free C implementation of the configuration utility, a shell convenience wrapper, and a set of examples that show what else could be built on top.

Editorial conclusion

Adopt wireguard-tools when you need the wg utility to configure a WireGuard interface, and use wg-quick when you want a shell script that handles the interface for you on a machine you control. Do not adopt wg-quick as the integration point for a managed network configuration, since the documentation itself suggests integrating wg or the WireGuard API into your network manager instead. Verify first that the install switches match your platform, in particular WITH_WGQUICK and WITH_SYSTEMDUNITS, and that the PREFIX and DESTDIR you set put the binaries and man pages where your packaging expects them.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. Project website
4. README
5. WireGuard/wireguard-tools on GitHub