Hello Debian Developers and Go Packaging Team, NFTBan v0.32.20 has reached feature-freeze and we are preparing for Debian Mentors submission.
Below is a brief summary of packaging details and open questions regarding DFSG, init-system support, and Go build policy. We’d greatly appreciate senior maintainer feedback before our first upload attempt. --- ## Executive Summary NFTBan is a production-ready nftables automation framework designed for security auditing and adaptive network defense. We’re targeting official inclusion into Debian via `mentors.debian.net` under MPL-2.0. **Project:** https://github.com/itcmsgr/nftban **License:** MPL-2.0 (DFSG-free) **Language:** Go + Bash **Build system:** debhelper compat 13, dh-golang **Init:** systemd service + sysv fallback (via dh_installinit) **Target:** Debian Bookworm / Trixie / Sid --- ## Packaging Overview ### 1. DFSG Compliance All components are MPL-2.0 licensed, with no external binaries or blobs. Upstream vendored Go modules will be **stripped** for Debian builds using `dh-make-golang` conventions. **Question:** - Q1.1: Is MPL-2.0 still considered DFSG-compatible without special license clarifications? - Q1.2: Should we provide `debian/copyright` using DEP-5 machine-readable format for Go module licensing metadata? --- ### 2. Source Layout and DEP-14 Our repository follows a hybrid structure: ``` main/ ├── cmd/feeds/ ├── cmd/geoip/ ├── internal/ ├── pkg/ └── packaging/debian/ ``` We intend to migrate to **DEP-14** branch naming (`debian/latest`, `debian/bookworm`, `debian/trixie`). **Questions:** - Q2.1: Should we maintain `debian/latest` or align directly to Debian releases (bookworm/trixie)? - Q2.2: Is DEP-14 now mandatory for new Go packages, or still recommended best practice? --- ### 3. Init System Compatibility NFTBan runs as a background daemon with systemd units and optional SysV scripts. **Questions:** - Q3.1: Is it acceptable to use systemd as default with SysV fallback via `dh_installinit`? - Q3.2: Are there preferred debhelper macros for timer-based services instead of cron? - Q3.3: Should timers install disabled by default (Debian Policy 9.11)? --- ### 4. Go Packaging Policy (dh-golang) We’re currently using Go 1.21 and plan to switch to `dh-golang` with minimal vendor data. **Questions:** - Q4.1: Should Go modules be vendored in the source tarball or removed for Debian builds? - Q4.2: Is `XS-Go-Import-Path: nftban` required in `debian/control` for non-library tools? - Q4.3: Should builds use `go generate` in `%build` or pre-generated assets? --- ### 5. Security and Linting Integration NFTBan includes an internal security self-check (`nftban-maintenance.timer`). It validates UID/GID, file integrity, and log retention. This timer is disabled by default on Debian. **Questions:** - Q5.1: Should we provide a `systemd-preset` file or leave activation manual? - Q5.2: Are timers acceptable for EPEL/Debian dual maintenance? - Q5.3: Should we include a `lintian-overrides` entry for Polkit rules and sysusers.d? --- ### 6. Debian Mentors Path and Sponsorship We intend to publish via **mentors.debian.net** and seek sponsorship from the **pkg-go** team. We will maintain an upstream watch file for GitHub releases and follow `uscan` versioning. **Questions:** - Q6.1: Should nftban go under the pkg-go team namespace, or as an independent package? - Q6.2: Are there specific mentors preferred for Go + systemd projects? - Q6.3: Any policy guidance for hybrid Go/Bash packages (dh-golang + shell hooks)? --- ### 7. Lintian and Policy Goals Current `lintian` results (clean except warnings): - `no-upstream-changelog` → resolved in v0.32.20 - `hardening-no-relro` → false positive (Go binary) - `binary-without-manpage` → adding sectioned manpages for CLI tools **Questions:** - Q7.1: Should nftban ship manpages for internal daemons too, or only user-facing commands? - Q7.2: Should we mark nftban-maintenance.timer as a “system service” in `debian/control`? --- ### 8. Log and State Handling By design, nftban preserves logs and config files on uninstall (`apt remove`). We follow Debian’s “preserve user data” principle but want to confirm expectations. **Questions:** - Q8.1: Should nftban purge logs on `apt purge` only? - Q8.2: Is `/var/lib/nftban/config/system.conf` acceptable under FHS? - Q8.3: Is it acceptable to keep `/var/log/nftban/` ownership as `root:root` post-uninstall? --- ### 9. Architecture and Build Reproducibility NFTBan builds reproducibly on amd64, arm64, and ppc64le under pbuilder/sbuild. No embedded timestamps are generated (`SOURCE_DATE_EPOCH` respected). **Questions:** - Q9.1: Should nftban adopt `reprotest` before submission? - Q9.2: Should we include a `Testsuite: autopkgtest-pkg-go` entry? - Q9.3: Is Salsa CI integration recommended prior to ITP? --- ## Contact Antonios Voulvoulis Founder & Architect — NFTBan Security by Design • Open Source Transparency https://nftban.com | https://github.com/itcmsgr/nftban
