netgate freebsd performance patch

[Lucid1010]

https://www.netgate.com/blog/ding-dong-ditch-the-doorbell-prank-in-freebsds-iflib
Is it possible to backport this patch to OPNsense, or should we wait until FreeBSD applies it?

[franco]

Same as always: wait for stable branch merge.

Also, are we going to hear Netgate praise itself every two weeks now on their blog for open source work while forgetting to push any CE code commits for 6 months?

Feels like a new marketing strategy.  I wish them the best.  :)


Cheers,
Franco

[Patrick M. Hausen]

FreeBSD already applied the fix to HEAD (write only once instead of thrice) and it will be MFC'd (backported to STABLE) in 2 weeks. The batched write enhancement is still under revision.

[Greelan]

forgetting to push any CE code commits for 6 months?

But, but...: https://forum.netgate.com/topic/201215/releasing-more-often-doesn-t-mean-more-secure

Why do they still have a chip on their shoulder? The obsession is unhealthy.

[viragomann]

Why do they still have a chip on their shoulder? The obsession is unhealthy.

Maybe because many users moved over to OPNsense for some reasons?
So did I. The reasons were discussed on both forums in several threads.

[Patrick M. Hausen]

That discussion even carried over to the TrueNAS forum.

[Seimus]

That discussion even carried over to the TrueNAS forum.

What, why, how...

[pfry]

Going back a ways, and pretty far out in left field... Back when I heard about [opnsense.com] I thought it was a pretty funny troll. (It was .com, wasn't it?) From a distance it seemed to show which side had a sense of humor. Turns out it really didn't break down that way.

Back at my first Internet job - tech support for a mainly dial-up ISP - we had a joke that we'd support anything. Simply put, helping people out was good PR. "Catch more flies". There's plenty of give and take between the two 'senses (e.g. the rather gentle poke above), but the core attitudes are a bit different. Netgate folks seem to subscribe to the zero-sum model of life; OPNsense folks do not seem to.

[franco]

But, but...: https://forum.netgate.com/topic/201215/releasing-more-often-doesn-t-mean-more-secure

That's cute.  I think this makes the same mistakes that the infamous Tom Lawrence video made.  I let my friend ChatGPT answer and leave the actual reasons for those CVEs and scores for someone who is genuinely interested in why things are going more and more into this direction and which CVEs likely still in pfSense today but we can't check because the source code is no longer available even for researchers... how inconvenient...

The post makes a valid technical point: frequent releases do not automatically mean better security. OPNsense has experienced several serious vulnerabilities, including recurring command-injection issues, and it's reasonable to question whether its development and review processes adequately prevent these problems. However, frequent updates are not inherently a weakness either. They can reduce the time users remain exposed to known vulnerabilities. The important measures are vulnerability prevention, patch quality, and time to remediation, not simply how often new versions are released.

The comparison with pfSense is statistically questionable and potentially misleading. The author compares just eight CVSS-scored pfSense vulnerabilities against 33 OPNsense CVEs, despite acknowledging that Netgate published 49 security advisories. These are not equivalent datasets, so comparing their average severity or claiming pfSense has a lower severity ceiling doesn't establish that pfSense is more secure. The post also applies different standards: OPNsense is criticized for existing vulnerabilities, while pfSense receives credit for its planned Go rewrite and System Patches mechanism. Meanwhile, OPNsense's own architectural hardening efforts receive little attention.

Overall, the post reads more like competitive advocacy than an impartial security analysis. It starts with an entirely reasonable premise, presents legitimate vulnerabilities, but then uses selectively framed statistics to suggest that pfSense has superior security engineering without actually demonstrating it. That doesn't necessarily mean the author is deliberately misleading, but the presentation creates an impression the evidence cannot support. Ironically, the author correctly argues that release frequency doesn't prove security, yet appears to suggest that lower reported CVSS scores do. Neither is a reliable measure on its own.


Cheers,
Franco on behalf of ChatGPT

[Greelan]

All of that said, there is no doubt a lesson in repeated CVEs happening due to similar reasons (input sanitization). I assume the tests have been hardened on that front.

As a matter of interest, does the development team use AI for vulnerability spotting?

[franco]

@greelan

Just briefly:

1. GitHub security advisories submissions are open since September 2025. This channel seems to be liked by researchers and yes there is a lot of AI generated content. How do we know? As soon as AI tools learn about a new type of vulnerability pattern 2 to 5 researchers are going to tell you about it independently.

2. GitHub makes CVE assignment as easy as pushing a button "Request CVE". We are guilty of using it.

3. 1. and 2. easily explain the surge of CVEs.

4. CVSS scoring fits an application running on a native Windows integration relatively well. Network-connected security tools where every single page is an access level down to the confiugration database and OS the scoring breaks down because a web GUI is a "remote access" by definition. The privilege system we inherited through shared history is also causing researchers to believe "limited" rights are not "full" admin rights even if you are on a firewall administration page. These things are unfixable and lead to higher scores. We've had a number of arguments about how scores are too high, but CVSS at face value is what it is. If pfSense says they don't have high scores that's quite strange, because everything translates 1:1 to their project. This is a fact of CVSS scoring and our shared project scope.

5. We have a LINCE certification since a number of years now.  Although it's on the back burner now we've also worked on reports via  https://scan.coverity.com/projects/opnsense-core -- but we don't use any AI tools to scan the code base.

6. As an example: https://github.com/opnsense/core/commit/10dd8619aea42 is a direct consequence of unguarded advanced input inherited from pfSense. I highly doubt they fixed it before we published it.

7. As another example: https://github.com/opnsense/core/commit/016f66cb4620 is an inherited bug fixed by them without issuing an advisory or CVE here https://github.com/pfsense/pfsense/commit/f0b0a03bbdca93 (as far as I know)

8. Communication with pfSsense is not possible due to constant bickering and belittlement mentality: https://www.reddit.com/r/PFSENSE/comments/1ottyh3/security_leadership_opnsenses_marketing_hype_vs/ -- It has been since the start. We could have shared reports and helped each other but that's not what the other side wants.

9. We've worked on privilege separation for almost 12 years now. Non-root web GUI option is available since

community/25.7/25.7:o system: allow experimental feature to run web GUI privilege separated as "wwwonly" user

and will likely be the factory default in 27.1:

https://github.com/opnsense/core/commit/63c8df03

10. We've removed mwexec() which was a source of many unguarded shell escapes throughout the inherited code base. This work was also done for more than a decade and finished this year:

community/26.1/26.1.r1:o Shell command escaping improvements and audit

11. Our latest community code is freely available for full third party scrutiny.  :)

12. We're proud of the code, improvements and fixes we've put out. We don't care what anyone but our users think and we're not afraid to make that clear.


Cheers,
Franco