OpenBSD Now! @openbsdnow@bsd.network

Consider two OpenBSD PF configurations:

pf1.conf, where SSH blocked by default, but internal LAN traffic is allowed:

block in on em0 proto tcp to port 22
pass in quick on em0 proto tcp from 192.168.0.0/16 to any

and updated pf2.conf, where someone added quick to the blocking rule "for safety's sake":

block in quick on em0 proto tcp to port 22
pass in quick on em0 proto tcp from 192.168.0.0/16 to any

quick was added to a broad block rule, silently shadowing the subsequent quick pass rule. Both are quick rules, both are present, and the change consists of just one word. A reviewer might reason: "The pass rule still has quick, so LAN traffic should still go through." However, among quick rules, the "first-match-wins" principle applies, not "last-match-wins": the block in quick rule now matches LAN traffic before the quick pass rule and shadows it. "Last-match-wins" only applies to non-quick rules. Visually, nothing appears broken, yet the behavior has changed.

And proofwall detect this:

$ ./proofwall diff -n 2 pf1.conf pf2.conf
DIFFERENT: rulesets are NOT semantically equivalent. Regressions (2): pass in A, block in B:
- 192.168.0.0:0 -> 0.0.0.0:22 proto=tcp flags=0x00 iface="em0" dir=in
- 192.168.0.0:0 -> 0.0.0.0:22 proto=tcp flags=0xff iface="em0" dir=in

Rule issues (1):
[B] line 2: redundant rule (removing it changes nothing): pass in quick on em0 proto tcp from 192.168.0.0/16 to any

This is interpreted as follows: a regression specifically for 192.168.0.0/16 -> tcp/22 (traffic that previously passed is now blocked), while the pass ... quick rule in the second config has become redundant - its effect is completely overridden by an earlier block quick rule.

OpenBSD 7.9 released

Release notes: https://www.openbsd.org/79.html
Announce: https://marc.info/?l=openbsd-announce&m=177919671915512&w=2

#release

Consider two OpenBSD PF configurations:

pf1.conf, where SSH blocked by default, but internal LAN traffic is allowed:

block in on em0 proto tcp to port 22
pass in quick on em0 proto tcp from 192.168.0.0/16 to any

and updated pf2.conf, where someone added quick to the blocking rule "for safety's sake":

block in quick on em0 proto tcp to port 22
pass in quick on em0 proto tcp from 192.168.0.0/16 to any

quick was added to a broad block rule, silently shadowing the subsequent quick pass rule. Both are quick rules, both are present, and the change consists of just one word. A reviewer might reason: "The pass rule still has quick, so LAN traffic should still go through." However, among quick rules, the "first-match-wins" principle applies, not "last-match-wins": the block in quick rule now matches LAN traffic before the quick pass rule and shadows it. "Last-match-wins" only applies to non-quick rules. Visually, nothing appears broken, yet the behavior has changed.

And proofwall detect this:

$ ./proofwall diff -n 2 pf1.conf pf2.conf
DIFFERENT: rulesets are NOT semantically equivalent. Regressions (2): pass in A, block in B:
- 192.168.0.0:0 -> 0.0.0.0:22 proto=tcp flags=0x00 iface="em0" dir=in
- 192.168.0.0:0 -> 0.0.0.0:22 proto=tcp flags=0xff iface="em0" dir=in

Rule issues (1):
[B] line 2: redundant rule (removing it changes nothing): pass in quick on em0 proto tcp from 192.168.0.0/16 to any

This is interpreted as follows: a regression specifically for 192.168.0.0/16 -> tcp/22 (traffic that previously passed is now blocked), while the pass ... quick rule in the second config has become redundant - its effect is completely overridden by an earlier block quick rule.

Cross-Platform GitHub Action supports OpenBSD https://github.com/cross-platform-actions/action#openbsd-openbsd

as weel as NetBSD, FreeBSD, DragonFlyBSD and MidnightBSD

I'm interested in issues related to OpenBSD packet filter misconfiguration. Could you provide examples of cases where access to resources was unintentionally opened or blocked due to misconfiguration? What do you typically use to prevent such errors?

Thanks in advance and thanks for sharing!

Patches for displaying bugs in the repository added using git-bug appeared in the cgit mailing list. Looks cool, right?

Demo: https://git.kernel.org/pub/scm/utils/b4/b4.git/bugs/

GoT has a planned feature for "web-based issue tracking component which stores data in a Git repository for easy replication and, ideally, offline editing" [3]. I can't wait for it to be implemented.

1. https://github.com/git-bug/git-bug
2. https://lists.zx2c4.com/pipermail/cgit/2026-August/005041.html
3. https://gothub.org/features.html

// CC: @gothub, @monsieuricon

Introducing the Himitsu keyring & password manager for Unix

https://drewdevault.com/blog/Himitsu/

Command Line Interface Guidelines
https://clig.dev/