Thanks for helping improve TunD. Keep changes small and aligned with the project scope: a lightweight, self-hosted virtual IPv4 LAN for trusted groups.
- TunD is not a general privacy VPN. Transport encryption exists, but traffic is not end-to-end encrypted against the server.
- Replay protection exists for TunD datagrams.
- The C core should stay dependency-light and close to the OS networking/TUN APIs.
- Platform-specific behavior should remain explicit and documented.
Run the smallest check that covers your change:
make test
make peerforge-check
make peerforge-wrong-key-check
make sanitize
make tools
make allFor a broader local verification:
make verifymake verify also runs the Windows cross-build, so it needs mingw-w64 and may need network access to download wintun.dll.
For GUI changes:
make gui-checkIf Flutter reports generated GUI files with wrong permissions, restore ownership of gui/build or gui/*/Flutter/ephemeral, then run make gui-clean.
- Keep the security model wording consistent. TunD datagrams are encrypted in transit and replay-protected. Traffic is not end-to-end encrypted against the server.
- Website sources live in
web/and are published by thePagesworkflow as the GitHub Pages site root. - Release steps are documented in
docs/RELEASE.md.
tools/sitest/contains the generic C test helper library.tests/support/contains test stubs and captures.tests/test_*.ccontains unit tests for protocol and core behavior.make peerforge-checkruns a local UDP integration check without real TUN interfaces.
Use concise conventional commit messages where possible, for example:
test: cover server packet handlers
fix: correct CI macOS artifact build
Keep commits atomic: one logical change per commit.