Contributor License Agreement (CLA)

Synapse is dual-licensed (Sustainable Use License + Enterprise License), so we ask every contributor to sign a CLA before we can merge their first pull request. The CLA grants Gen0Sec the right to relicense contributions across both license tracks, including the Enterprise tracks — without it, we can't lawfully include community contributions in the paid modules.

There are two CLAs; pick the one that fits your situation:

Individual CLA (default)

Most contributors use the Individual CLA. Signing is automated: when you open your first pull request, the CLA Assistant workflow will check your status and, if needed, post a comment with a one-line response you can paste to sign. It's a one-time action per GitHub account; future PRs are gated automatically.

Bot accounts (dependabot, renovate, github-actions) are exempt.

Corporate CLA (for companies)

If you're contributing on behalf of a company that cannot bind itself through individual click-through (common at large enterprises, regulated industries, and any org whose policy requires a company-to-company IP contract), use the Corporate CLA instead.

Process:

1. Your legal team reviews .github/CORPORATE_CLA.md.
2. An authorized officer signs it (electronic signature is fine).
3. Fill in Schedule A with either named employees + their GitHub usernames, or org-wide coverage by email domain / GitHub org.
4. Email the signed CCLA to legal@gen0sec.com.
5. Gen0Sec countersigns and adds the covered GitHub accounts to the CLA Assistant allowlist. Future PRs from those accounts bypass the per-PR ICLA prompt.

The CCLA only needs to be signed once per company; Schedule A can be updated by email as employees join or leave.

Development environment

Install deps (Ubuntu 24.04):

sudo apt-get install -y git build-essential clang llvm \
libelf-dev libssl-dev \
zlib1g-dev libzstd-dev pkg-config libcap-dev \
binutils-multiarch-dev curl cmake

vmlinux.h generation notes

This workspace contains a vmlinux.h header generated from the running kernel's BTF.

How it was fixed:

• The error failed to load BTF from /sys/kernel/btf/vmlinux: Invalid argument occurred because the system bpftool (v5.15.x) was too old to parse the kernel 6.10 BTF types.
• We built a newer bpftool from the Linux v6.10 sources, which uses a recent libbpf with support for new BTF kinds.

Steps to regenerate:

1. Build bpftool from kernel tools:

   git clone --depth=1 --branch v6.10 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git /tmp/linux
   make -C /tmp/linux/tools/bpf/bpftool -j$(nproc)
   sudo make install -C /tmp/linux/tools/bpf/bpftool
   

2. Generate header:

   /usr/local/sbin/bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.h
   

Tip: You can also use /usr/local/sbin/bpftool btf dump file /sys/kernel/btf/vmlinux > vmlinux.json if you want to inspect raw BTF in JSON form.

bpftool version used during this run:

• /usr/local/sbin/bpftool -V => v7.5.0, libbpf v1.5