wireguard-go — Dependencies#

Module info#

Module: golang.zx2c4.com/wireguard
Go version: 1.23.1
Direct dependencies: 5
Indirect dependencies: 2
go.sum entries: 14 lines (7 unique modules — a perfect 1:1 correspondence with 5+2 declared deps)

Dependency categories#

Cryptography#

golang.org/x/crypto v0.37.0 — The core of the WireGuard noise protocol. Used in device/ for:
- chacha20poly1305 — symmetric authenticated encryption for data packets
- blake2s — BLAKE2s hashing for key derivation and MAC operations
- curve25519 — Elliptic-curve Diffie-Hellman for ephemeral and static key exchange
- poly1305 — MAC used in handshake message authentication This is the single most critical dependency; the entire cryptographic security of WireGuard rests on it.

Platform / OS integration#

golang.org/x/sys v0.32.0 — Syscall wrappers for both Unix (unix package) and Windows (windows package). Used extensively in tun/, conn/, and rwcancel/ for TUN device management, socket options, epoll/kqueue, and Windows I/O completion ports. Critical for the platform-specific file abstractions.
golang.zx2c4.com/wintun v0.0.0-20230126152724-0fa3db229ce2 — Windows TUN kernel driver (wintun.dll) binding. Used exclusively in tun/tun_windows.go. This is a C-backed driver by the same author (Jason Donenfeld); its Go module wraps the DLL import. Required only on Windows builds.

Networking#

golang.org/x/net v0.39.0 — Extended networking primitives used in tun/netstack/. Specifically: dns/dnsmessage (DNS packet encoding), icmp, ipv4, ipv6. Used to implement a full DNS resolver and ICMP handler within the userspace netstack integration. Not used in the main device or conn layers.

Userspace TCP/IP stack (optional)#

gvisor.dev/gvisor v0.0.0-20250503011706-39ed1f5ac29c — Google’s gVisor userspace OS kernel, used only in tun/netstack/tun.go. This is the heaviest dependency by far (brings in two indirect deps). It provides a complete userspace TCP/IP stack (tcpip/stack, tcpip/network/ipv4, tcpip/transport/tcp, etc.), enabling WireGuard to run without kernel networking — useful in containers or sandboxed environments. The gvisor.dev/gvisor/pkg/buffer and pkg/waiter packages handle zero-copy buffers and I/O event waiting.

Indirect dependencies#

github.com/google/btree v1.1.2 — Pulled in by gVisor for internal data structure use (route tables, segment trees). Not directly imported by wireguard-go code.
golang.org/x/time v0.7.0 — Pulled in by gVisor for rate limiting utilities. Not directly imported by wireguard-go code.

Testing#

None. All tests use only stdlib testing. No testify, gomock, or assertion libraries appear anywhere in the codebase.

Stdlib reliance#

wireguard-go is an extremely stdlib-heavy project. The non-optional, non-platform code in device/, ratelimiter/, replay/, tai64n/, and ipc/ uses only stdlib — no external imports at all. The most-used stdlib packages are:

Package	Used for
`sync`, `sync/atomic`	Peer state, session tables, device lifecycle
`crypto/cipher`, `crypto/hmac`, `crypto/rand`, `crypto/subtle`	Supplemental cryptographic operations alongside x/crypto
`net`, `net/netip`	IP address representation, UDP sockets
`container/list`	Handshake queue management
`encoding/binary`, `encoding/hex`	Wire format serialization
`os`, `syscall`, `runtime`	Platform detection, TUN device lifecycle
`log`	Logging (no third-party logger)
`time`	Session expiry, keepalive timers

Third-party code is a thin augmentation layer on top of stdlib, not a replacement for it.

Shared dependencies#

Dependencies that appear across multiple projects in the analyzed set:

golang.org/x/crypto — Near-universal in security and networking projects (caddy, traefik, etcd, Kubernetes, etc.)
golang.org/x/sys — Near-universal for any project requiring OS-level syscall work
golang.org/x/net — Common in networking-oriented projects (caddy, traefik, hugo)
github.com/google/btree — Appears as indirect dependency in several projects using gVisor or Google libraries
golang.org/x/time — Common utility, appears indirectly in many projects

wireguard-go has the smallest direct dependency set of any network-infrastructure project likely to appear in this analysis. Its 5 direct deps are all either from the Go extended standard library (golang.org/x/*) or from the WireGuard project itself (golang.zx2c4.com/wintun). Only gVisor is a “real” third-party dependency.

Vendoring#

No vendor/ directory. The project uses the standard Go module proxy and does not vendor. This is consistent with its minimal dependency footprint — with only 7 total modules, vendoring offers little benefit and would add significant repository bloat (especially given gVisor’s size).

Notable dependency decisions#

Zero test dependencies. The complete absence of testify or any assertion library is deliberate. The codebase tests cryptographic correctness and protocol behavior using raw testing.T comparisons — a style that emphasizes clarity over convenience, fitting for security-critical code.
x/crypto over stdlib crypto. Go’s stdlib crypto/ packages lack ChaCha20-Poly1305, BLAKE2s, and Curve25519, so golang.org/x/crypto is the natural choice. Notably, wireguard-go does also use crypto/hmac, crypto/cipher, crypto/rand, and crypto/subtle directly from stdlib for operations those packages cover.
gVisor scoped to one package. The heaviest dependency (gVisor) is cleanly isolated in tun/netstack/. If you build without that package, gVisor and both its indirect deps are pruned from the build graph. This is Go module pruning working exactly as intended.
wintun is a same-author dep. golang.zx2c4.com/wintun is maintained by Jason Donenfeld (WireGuard’s author), so it’s effectively an in-house dependency despite being a separate module. It wraps a kernel driver DLL that ships alongside the binary on Windows.
No logging or config framework. The binary uses stdlib log and flag directly. This keeps the binary small and the dependency graph clean — a philosophical stance aligned with the Unix tool ethos and the security-minimalism of the WireGuard project overall.