Working on it
The most useful thing you can do is not a patch. It is running this somewhere we cannot, and telling us what broke.
That is not modesty about patches; it is the actual reason the enforcement core is open. A security data plane earns durability by meeting real environments and real adversaries, and no single author can reproduce those. Every network has a middlebox, a captive portal, a pinned application or a certificate policy that our lab does not. A precise bug report from one of them is worth more here than most features.
What the codebase is
- Go, as importable packages. Not a monolith with an API bolted on —
the enforcement path is a library, and the reference binaries are thin. You can
import
policy,swgoreastwestinto something of your own without taking the rest. - A macOS Network Extension in Swift, and a Windows WFP agent with a first-party callout driver. These are the parts that need a real machine — an OS-level flow capture cannot be unit-tested into existence. Note that the driver is kernel-mode and not yet attestation-signed, so working on it today means a machine in test-signing mode (why).
- An egress engine that links a native library through cgo. It is why a decrypt-all deployment is two processes and not one static binary, and why the third-party licence inventory is hand-maintained: a Go dependency scan cannot see it.
Getting it building
go build ./...
go vet ./...
go test ./...
# the Windows steering agent cross-compiles:
GOOS=windows GOARCH=amd64 go build ./clients/windows-wfp/steer/
# the macOS network extension (needs a Swift 6 toolchain):
cd clients/macos-network-extension && swift build && swift test
CI runs the same checks on every pull request, and contributions are accepted under the
Developer Certificate of Origin — sign
off every commit with git commit -s.
What a good change looks like
- One logical change per pull request.
- Tests for behaviour changes. If a test would have caught the bug you are fixing, that test is the more valuable half of the patch.
- Fail-closed stays fail-closed. The reference edge and control plane must never serve over plaintext, and detection or observation must never auto-bypass enforcement.
- Comments that are still true after the change. An accurate comment is part of it.
What will be turned down, and why
Written here rather than discovered in review, because these are the changes most likely to look like obvious improvements.
- A fallback for the egress engine. A Go emulation is the fingerprint bot management already rejects, so falling back to one converts a single legible failure — the broker is down — into scattered per-origin breakage that nobody can diagnose. Failing the flow is the feature.
- Anything that lets a licence stop traffic. A licence may refuse new enrolments beyond its scope. It may not stop steering, cut flowing traffic, halt an edge, or disable features. You can check the current state yourself: the predicates that would do it exist and have zero call sites outside their own tests, and that absence is deliberate rather than unfinished.
- Weakening a default or a document to make a check pass. If a check fails, either the implementation is wrong or the claim was too broad. Both are fixed by changing the thing, not the assertion about it.
- A capability that is not reachable from a test or a runnable example. This project's whole argument is that its claims can be checked. A feature nobody can exercise is a claim nobody can check.
Honestly, about response times
This is maintained by a very small team, asynchronously. A pull request may sit for days. Opening an issue before a large change is worth it — not as process, but because it is genuinely possible to write something good that does not fit, and finding that out afterwards is nobody's idea of a fair trade.
The repository opens on 2026-09-01 at github.com/lantern-networks/dsse-core. Until then there is nothing to build. Where to ask what.