CLI Tool to Convert Openbsd Packet Filter Config Files to JSON and Vice Versa
Posted3 months agoActive3 months ago
github.comTechstory
supportivepositive
Debate
20/100
OpenbsdPacket FilterJSON Conversion
Key topics
Openbsd
Packet Filter
JSON Conversion
A CLI tool for converting OpenBSD Packet Filter config files to JSON and vice versa was shared, sparking discussion on its utility and potential applications.
Snapshot generated from the HN discussion
Discussion Activity
Moderate engagementFirst comment
3d
Peak period
10
Day 3
Avg / period
4.7
Comment distribution14 data points
Loading chart...
Based on 14 loaded comments
Key moments
- 01Story posted
Oct 3, 2025 at 2:01 PM EDT
3 months ago
Step 01 - 02First comment
Oct 6, 2025 at 10:23 AM EDT
3d after posting
Step 02 - 03Peak activity
10 comments in Day 3
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 13, 2025 at 6:59 AM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45465821Type: storyLast synced: 11/20/2025, 2:36:48 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
[1]: https://www.youtube.com/watch?v=MvFHT0N9inw (Just Try Out New Languages - part of a longer interview)
[2]: https://news.ycombinator.com/item?id=43462676 (TUI editor and Vim/Neovim alternative)
[3]: https://github.com/vlang/awesome-v
So, other than validation or something... Which, if you are already parsing the file into json and back again... Means you already can parse pf.conf files, and just do validation directly there.
So if it's just backing up, then yeah why add the extra step of converting the file before backing it up
JSON is generally a pretty poor configuration language, so I wouldn't hope that it would be adopted.
I suspect that the purpose of this is to be able to ingest pf.conf files into a larger security tool. Something like an NDR/XDR/SOAR, or perhaps Splunk.
SecOps wants to know what the existing policies are (for compliance and validation), and to orchestrate enforcement when an IoC (or whatever) prompts investigation and action. Getting the format into JSON opens up the whole landscape for integration into existing tooling.