Rename blacklist to blocklist, following upstream

[laffer1]

Upstream renamed the blacklist project to blocklist. This follows the rename on master only, mirroring what FreeBSD did in 7238317403b9 ("blocklist: Rename blacklist to blocklist"), including the compatibility shims so existing setups keep working with a warning.

What changes

• New vendor branch vendor/blocklist, tagged vendor/blocklist/20260409, importing upstream https://github.com/zoulasc/blocklist at 46419aa (2026-04-09). contrib/blacklist is removed and contrib/blocklist is read in from the vendor branch, with MIDNIGHTBSD-upgrade and midnightbsd-changes.sh describing the procedure and the local adaptations.
• New names built: libblocklist(3), blocklistd(8), blocklistctl(8), /etc/blocklistd.conf, rc.d/blocklistd, blocklistd_enable / blocklistd_flags, blocklistd-helper, and the WITH[OUT]_BLOCKLIST / WITH[OUT]_BLOCKLIST_SUPPORT build options.
• Consumers updated to the blocklist API: sshd (UseBlocklist, with UseBlacklist kept as an alias), ftpd and fingerd. Their client glue files are renamed from blacklist.c to blocklist.c.
• Compatibility kept for now: libblacklist, blacklistd, blacklistctl and blacklistd-helper are built from FreeBSD's compatibility sources in contrib/blocklist; the blacklistd rc script still works but warns; the old WITHOUT_BLACKLIST* knobs are wired to the new ones. The periodic pf check looks at both anchor names.
• UPDATING entry, src.conf(5), option docs and OptionalObsoleteFiles.inc updated.

Testing

Built with a private MAKEOBJDIRPREFIX on amd64: lib/libblocklist, lib/libblacklist, usr.sbin/blocklistd, usr.sbin/blocklistctl, usr.sbin/blacklistd, usr.sbin/blacklistctl, libexec/fingerd, libexec/ftpd, secure/lib/libssh, secure/libexec/sshd-session and secure/libexec/sshd-auth all build cleanly under -Werror. Every consumer links against libblocklist.so.0. libblacklist.so.0 exports the old blacklist_* symbols plus the new blacklist_open2. blocklistd -d parses the shipped configuration. All rc and helper scripts pass sh -n.

Not done: a full buildworld / installworld and a live test of the daemon against pf. Please give the pf integration a run before merging.

Notes for review

• contrib/blocklist/port/config.h is a three line local wrapper that upstream generates with autoconf; it is documented in MIDNIGHTBSD-upgrade.
• The compatibility sources (old_bl.c, blacklist.c, old_internal.[ch], include/blacklist.h, include/old_bl.h, bin/blacklistd.c, bin/blacklistctl.c) and the old-name manual pages are taken from FreeBSD main unchanged.
• The last column of blocklistd.conf is now called duration (formerly disable); the installed default rules are unchanged.

AI-Assisted-by: Claude Fable 5.1
Obtained from: FreeBSD 7238317403b95a8e35cf0bc7cd66fbd78ecbe521

🤖 Generated with Claude Code

[sourcery-ai]

Sorry @laffer1, your pull request is larger than the review limit of 150,000 diff characters

[github-actions]

Claude finished @laffer1's task in 3m 51s —— View job

---

Claude finished reviewing this PR

Todo list

• Gather context (read CLAUDE.md, diff against origin/master)
• Review contrib/blocklist vendor import & local adaptations
• Review consumer changes (sshd, ftpd, fingerd, libexec/blocklistd-helper)
• Review build system changes (Makefiles, options)
• Review docs (UPDATING, man pages, src.conf)
• Post final review

Summary

This is a well-executed, mechanical rename that mirrors FreeBSD's upstream change closely, with sensible compatibility shims. No contrib/mksh or assembly changes are present, so nothing here falls under an AI-review restriction. contrib/blocklist/* is vendor-imported (largely unchanged from FreeBSD), so I focused review effort on the hand-written glue: build Makefiles, rc scripts, consumer diffs (sshd/ftpd/fingerd), and the src.opts.mk aliasing logic.

Findings

Minor — inconsistent LDFLAGS/LIBADD library reference in the compat programs
usr.sbin/blacklistd/Makefile:12 and usr.sbin/blacklistctl/Makefile:10:

LDFLAGS+=-L${LIBBLACKLISTDIR}
LIBADD+= blocklist util

Both compat programs actually link against the new libblocklist (confirmed via Makefile.depend, which lists lib/libblocklist, not lib/libblacklist), matching blocklistd/blocklistctl's own Makefiles. The -L${LIBBLACKLISTDIR} line therefore points at the wrong (and functionally unused) object directory — a likely leftover from the rename script. It isn't build-breaking (LIBBLACKLISTDIR is unconditionally defined in src.libnames.mk, and the real link path comes from the LIBADD machinery), but it's misleading and should probably read -L${LIBBLOCKLISTDIR} or be dropped, consistent with the non-compat Makefiles.

Things I verified as correct (no issues found)

• share/mk/src.opts.mk: the new MK_BLACKLIST/MK_BLOCKLIST (and *_SUPPORT) mutual-aliasing block forces both knobs to stay in sync, so downstream code that only guards on one of the two (e.g. tools/build/mk/OptionalObsoleteFiles.inc's single .if ${MK_BLOCKLIST} == no covering both old and new OLD_FILES) is safe.
• crypto/openssh (auth.c, auth-pam.c, monitor.c, servconf.c/h, sshd-session.c) and libexec/ftpd, libexec/fingerd: renames are consistent and complete; UseBlocklist/UseBlacklist alias ordering in servconf.c looks correct (new name is canonical, old name maps to the same opcode).
• midnightbsd-changes.sh local adaptations (RT_ROUNDUP→SA_SIZE, npfctl→ipf/ipfw/pfctl) are actually applied in the vendored bin/conf.c and bin/blocklistd.8.
• usr.sbin/periodic/etc/security/520.pfdenied now checks both the blacklistd and blocklistd pf anchors.
• libexec/rc/rc.d/blacklistd and the new blocklistd rc script are both valid sh, print a deprecation warning, and correctly wire rcvar/required_files to their respective names.
• lib/libblacklist/Makefile vs lib/libblocklist/Makefile: correctly build from old_bl.c vs bl.c respectively, preserving the old ABI/symbol set (blacklist_open2 compat addition looks intentional and matches upstream NetBSD).
• contrib/blocklist/etc/blocklistd.conf / usr.sbin/blocklistd/blocklistd.conf: consistent duration column header, matches the PR description.

Overall this looks solid and low-risk given the compatibility-first approach. The one Makefile nit above is cosmetic and worth a quick cleanup but doesn't block anything. As noted in the PR body, the pf integration live-test is still outstanding — I did not attempt to build or run anything in this environment (network access for git fetch is unavailable here, so I reviewed against the locally cached origin/master).