What about (security) updates available on the official Rocky repo’s?

[LayLow]

@davidep

At the same time, I’m not sure this automatically creates the need to discuss every security bulletin here. Raising awareness is important, especially for issues affecting the underlying OS and shared components, but every distribution already has its own security advisories and dedicated discussion channels. We should probably avoid duplicating those efforts in the forum.

When a project like NethServer chooses to take control of the update streams and disable the default Rocky Linux repositories, they effectively become the gatekeeper.

At that exact moment, the conversation shifts from a purely legal one to a matter of moral and ethical responsibility. This dynamic highlights a major tension point in the modern open-source ecosystem: the trade-off between stability and immediate security.

Here is why this argument holds serious moral weight, why the current reality looks the way it does, and how we as system administrators should navigate it.

The Moral Case for Transparency

When Nethesis holds back or delays upstream updates in ns-baseos to ensure they don’t break NethServer’s custom UI or container architecture, they are making a risk calculation on behalf of the user.

If a critical Remote Code Execution (RCE) vulnerability is actively being exploited in the wild, and Rocky Linux has a patch ready, but a NethServer instance cannot pull it because the ns-baseos mirrors haven’t been synchronized yet, the end-user is left exposed. In this scenario, the bare minimum ethical requirement should be:

1. Immediate Transparency: Acknowledge that a critical upstream vulnerability exists.

2. Status Updates: Explain why the update is being held back (e.g., if it breaks core NethServer functionality).

3. Actionable Mitigation: Provide the community with manual workarounds (like temporary firewall rules or disabling affected services) until the official update drops.

The Friction: Open Source vs. Commercial Survival

So, why doesn’t Nethesis do this systematically on the public forum? It usually comes down to a mix of resource constraints and commercial strategy:

• The Resource Trap: While Nethesis is a commercial entity, the NethServer community forum relies heavily on a small core team and community volunteers. Tracking every single upstream Red Hat/Rocky Linux CVE, analyzing its specific impact on NethServer, and drafting public advisories takes significant engineering time—time they often choose to spend on development.

• The Commercial Incentive: This is the harder truth. Nethesis funds the development of NethServer through its paid Enterprise Subscriptions. Proactive security monitoring, rapid vulnerability assessments, and direct mitigation advisories are precisely the value-adds kept behind the paywall. Providing high-tier security dispatch for free on the public forum directly competes with their primary revenue model.

How We as Administrators Can Respond

Relying solely on hope for a vendor’s moral obligation is rarely a sound security strategy. If you are running the community edition, you have a few ways to address this gap:

• Push for a Dedicated Security Channel: Bring this exact perspective to the NethServer forum. The project has historically been receptive to community feedback. If enough administrators advocate for a dedicated, low-noise “Security Announcements” category specifically for critical upstream gatekeeping events, it pushes the maintainers to formalize a communication standard.

• Take Back Manual Control (The Risk Trade-off): In the event of a known active exploit, administrators always have the technical option to temporarily override ns-baseos restrictions, manually enable the official Rocky Linux security repositories, and force-patch the underlying OS. While this introduces a risk of breaking NethServer-specific features, it allows you—not the vendor—to make the final risk assessment between a broken UI and a compromised server.