Ok, lots of questions around 'why' and no answers, so let me take a stab.
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.
Nice, that's a reasonable use case. I've been working on centralizing my home lab config and this tool could help bring pf.conf in/out of a central JSON config. Mine already handles static DHCP leases, local hostnames, certificates, etc.
So asking a real question not being sarcastic and having only dabbled with OpenBSD's pf, what is the use for this? The examples seem to point to using it for backups, but what does json give you versus just backing up the file directly? Is it to make manipulating pf config files programmatically easier?
No. You're not being sarcastic here. PFs config files can't really be any more complicated or easier in json than in its native form.
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
I assumed it was to make it easier working with the files programmatically. Eg using jq or one of the many many other solutions for JSON in shell scripts.
Neat, but why? I could see this being handy if the pf language was changed and this tool could covert between the old and new configuration. I believe pf have been substantially updated in the past and I don't recall there being a conversion tool.
I'm not affiliated with the project but I believe the chance of OpenBSD adopting JSON as a config file format are approximately zero, to whatever degree of precision you might choose.
Sounds about right, but they also don't need to, all the OpenBSD specific configuration is mostly done in the same manor, meaning that if you know PF, then the configuration language for httpd, relayd or OpenSMTPd isn't all that foreign to you.
JSON is generally a pretty poor configuration language, so I wouldn't hope that it would be adopted.
Ok, lots of questions around 'why' and no answers, so let me take a stab.
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.
Nice, that's a reasonable use case. I've been working on centralizing my home lab config and this tool could help bring pf.conf in/out of a central JSON config. Mine already handles static DHCP leases, local hostnames, certificates, etc.
That was my first gut instinct too. Good to know I am not alone. :)
So asking a real question not being sarcastic and having only dabbled with OpenBSD's pf, what is the use for this? The examples seem to point to using it for backups, but what does json give you versus just backing up the file directly? Is it to make manipulating pf config files programmatically easier?
No. You're not being sarcastic here. PFs config files can't really be any more complicated or easier in json than in its native form.
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
I assumed it was to make it easier working with the files programmatically. Eg using jq or one of the many many other solutions for JSON in shell scripts.
Total aside, but I LOVE that it's written in a non-top10 language without the "in [language]" comment.
For some reason I was under the impression that V (Vlang) was vaporware. Nice to see something built in it.
Is that the reason this is being upvoted? Otherwise what is the purpose of converting pf.conf to JSON?
Neat, but why? I could see this being handy if the pf language was changed and this tool could covert between the old and new configuration. I believe pf have been substantially updated in the past and I don't recall there being a conversion tool.
I'm not affiliated with the project but I believe the chance of OpenBSD adopting JSON as a config file format are approximately zero, to whatever degree of precision you might choose.
The pf language is also shockingly readable for a firewall config
Sounds about right, but they also don't need to, all the OpenBSD specific configuration is mostly done in the same manor, meaning that if you know PF, then the configuration language for httpd, relayd or OpenSMTPd isn't all that foreign to you.
JSON is generally a pretty poor configuration language, so I wouldn't hope that it would be adopted.