[pkg-go] [RFS] nftban v0.32.20 — DFSG review, DEP-14 workflow & init system flexibility

[Antonios Voulvoulis]

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