The OPNsense Plugins System Situation

[Majx]

I would first like to thank the OPNsense team for all of their hard work and the consistent support they provide to the community.

I'm not sure whether this topic has been discussed before. I searched the forum but couldn't find a clear discussion about it. If this has already been addressed, I would appreciate being pointed to the relevant resources.

Introduction

Many of us invest our free time developing plugins for OPNsense.

From what I have observed, there are currently two ways to publish a plugin for public use:

• Host your own repository
  Developers can maintain a separate repository, host the plugin themselves, and provide users with command-line instructions to add the repository to their system. Once added, the plugin appears under System → Firmware → Plugins.
  
• Submit the plugin to the official repository
  Developers can contribute their plugin to the opnsense/plugins repository, allowing it to appear directly in the default OPNsense plugin list without requiring users to add external repositories.
  

Where Is the Problem?

If a developer wants their plugin to be easily discoverable by users, the most practical route is publishing it under the official opnsense/plugins GitHub repository. However, doing so requires compliance with the BSD-2-Clause license and effectively places the code under the project's governance and license. For some developers, this creates concerns about licensing flexibility and long-term control over their work.

On the other hand, publishing plugins in private repositories significantly reduces their visibility, meaning many users may never discover them unless they happen to find them independently and manually add the external repository to their system in order to install the plugin.

This creates a trade-off between visibility and accessibility versus licensing flexibility and control.

Possible Solution?

One possible approach would be to implement an official plugin registry or indexing system within OPNsense, enabling third-party developers to register plugin metadata (name, description, version, repository URL) and have these plugins displayed via the "Show Community Plugins" section of the GUI.

This approach would maintain developer ownership and licensing flexibility, improve the visibility of third-party plugins, and enhance the user experience. It would also strengthen OPNsense as a platform, since there are plugins that expand its capabilities currently exist outside the official repository and are not widely known. Furthermore, it could reduce maintenance overhead by enabling plugin-related issues and support to be managed by their respective maintainers instead of being centralized within the opnsense/plugins project.

I would be very interested to hear the thoughts of the OPNsense team and the community on this matter.

[franco]

> licensing flexibility

Hmm, you want to contribute 2-Clause BSD code? Sure. You want leeway? Nope.

Third party repositories reachable through the plugins are allowed for business partnerships. We only have one such vendor which is SunnyValley a.k.a. Zenarmor. Intentionally we avoid having non-reviewable binaries in our core, plugins and ports. The vendor repo plugins are the only way to deliver this natively to users. The threshold for another vendor repository are very high, not something for normal BSD license users to achieve.

The biggest issue with the plugin system at the moment is that we don't have enough time to vet PRs and submission and even cover the use cases of the plugins proposed. AI is used more and more to generate full plugins in a heartbeat. We will likely have to say "no" more than before to make time for other submissions.

On the subject of binaries... if you have the source code in the open addition to FreeBSD ports is the usual way to get it intergrated as a plugin because that adds peer review to the functionality and reduces risk over security concerns (now or in the future). In some cases binaries for OPNsense are allowed (ndp-proxy-go, opnsense-filterlog) because their scope is narrow or a trusted source on top of open source code (and the open source license there doesn't matter).

The question I'm asking me is how much non-permissiveness you want in a free product that ships your code?


Cheers,
Franco

[Majx]

Thank you for your reply Franco.

I believe there may have been a small misunderstanding and that I may not have expressed my point clearly enough in my original post.

> Hmm, you want to contribute 2-Clause BSD code? Sure. You want leeway? Nope.

I completely understand and agree that OPNsense is licensed under 2-Clause BSD and that any contribution to core, plugins, or ports must follow that same license. I am not looking for exceptions or alternative licensing inside the official repositories. The integrity of the project depends on consistency, and I respect that.

> The biggest issue with the plugin system at the moment is that we don't have enough time to vet PRs and submission and even cover the use cases of the plugins proposed. AI is used more and more to generate full plugins in a heartbeat. We will likely have to say "no" more than before to make time for other submissions.

Regarding the current pressure on the plugin system and the limited time available to vet PRs, I fully understand the challenge as the volume of contributions can easily exceed what is realistically reviewable. That is one of the reasons why I was thinking about a new structural separation instead of the current broad inclusion.

> On the subject of binaries... if you have the source code in the open addition to FreeBSD ports is the usual way to get it intergrated as a plugin because that adds peer review to the functionality and reduces risk over security concerns (now or in the future).

My proposal is not about introducing non-reviewable binaries into core. Instead, what I am trying to explore is whether plugin discoverability must necessarily require governance and code inclusion.

In other words, there could be a conceptual difference between "official plugins" that are reviewed, merged, and maintained under the OPNsense umbrella, and "community-listed plugins" that remain entirely owned and maintained by their original developers. These would not be part of the official repositories and not maintained by the OPNsense team. They would simply be discoverable through a structured registry mechanism inside the GUI. Installation could require an explicit opt-in action from the user, such as enabling a "community sources" section or confirming a clear trust warning, without requiring manual command-line repository configuration.

Such a separation would preserve the strict review standards and security model of OPNsense, while avoiding additional maintenance burden for the core team. It would also make the trust boundary explicit to users, for example by clearly distinguishing official plugins from externally maintained ones. That would provide visibility without transferring responsibility.

If even listing external plugins creates an implied endorsement that the project is not comfortable with, I completely understand that position. My goal is not to argue against the current standards, but to explore whether there is room for a middle ground between full integration and practical invisibility.

Thank you again for taking the time to respond and for making OPNsense reliable and trusted.

/Majx

[franco]

> These would not be part of the official repositories and not maintained by the OPNsense team. They would simply be discoverable through a structured registry mechanism inside the GUI.

That's already the case with the simple drop of a repository configuration. I don't believe we need:

1. A GUI for dropping configuration files (against security policy)
2. A builtin list of external repositories that needs to be managed and shipped somehow (we already scale back on official mirrors in the GUI list as they stop working and you can just drop a URL in the GUI anyway)
3. It emulates what we already have with "community tier" plugins and checkbox and overcomplicates the tier system with basically any other thing that someone could have built.

Your idea makes sense, but it would give legitimacy to plugins that are not vetted. Thus we'd like to force people through the console to set them up themselves as it goes for overrides and custom options as per our security policies.

> My proposal is not about introducing non-reviewable binaries into core.

I just wanted to make this part clear, because it is an uncontrollable risk in your suggestion, because nobody is vetting the code.

> It would also make the trust boundary explicit to users, for example by clearly distinguishing official plugins from externally maintained ones. That would provide visibility without transferring responsibility.

I don't think that's the case. If it's in the GUI it is is legitimate no matter how many warnings are being displayed. We have two big warnings in the GUI with HTTPS and SSH listening interfaces that says "I know what I'm doing" but people still report their bugs regarding this in the forum. It does not work. A GUI click is NOT a responsibility shift in the minds of (some) users.


Cheers,
Franco

[Majx]

> Your idea makes sense, but it would give legitimacy to plugins that are not vetted.

That concern is valid, and I agree it is one of the main risks in the current proposal. However, I do not think the proposal has to be adopted exactly as written. It can be refined and improved.

The objective is to shift responsibility and maintenance burden to plugin authors while allowing the core team to focus more on OPNsense itself. If we can design a model that makes plugin creators clearly responsible for their own code, without implying endorsement or legitimacy by the core project, then we could achieve that goal without compromising security standards.

At the moment, the team spends significant time reviewing PRs, vetting plugins, and maintaining a large and growing ecosystem. As OPNsense continues to grow in popularity, that workload will only increase. Reducing that overhead would directly benefit the core product and its long term stability.

> I just wanted to make this part clear, because it is an uncontrollable risk in your suggestion, because nobody is vetting the code.

It is indeed an uncontrollable risk to some extent. The real question is who owns that risk.

If third party plugins are clearly separated from the OPNsense core, both technically and in terms of branding and messaging, then the responsibility shifts to the user who decides to install them. Many software ecosystems operate this way. Not every extension is vetted by core maintainers, but they are clearly identified as community maintained or third party.

As long as there is no implied endorsement and users are clearly informed that these plugins are not reviewed by the core team, the responsibility model becomes much clearer.

> A GUI click is NOT a responsibility shift in the minds of (some) users.

That is true to a certain degree. Some users will always assume that if something appears in the GUI, it is officially supported.

However, we also have to define reasonable boundaries. It is not realistic to eliminate every possible misunderstanding. At some point, clear labeling and explicit warnings have to be considered sufficient.

If the interface clearly states that certain plugins are community maintained, not reviewed by the core team, and installed at the user's own risk, then the project has taken reasonable steps to communicate that distinction.

Ultimately, this is about balance. We need to protect the reputation and security posture of OPNsense, avoid an unsustainable maintenance burden for the core team, and still allow the ecosystem to grow without becoming a bottleneck.

I am not arguing for removing safeguards. I am just suggesting that we explore a structure that preserves the security expectations while enabling the project to scale. If we do not adjust the model, the maintenance burden of plugins will only continue to grow, and that may become a larger long term risk than clearly marked third party plugins.

/Majx