When will Nethesis release the massive amount of (security) updates available on the official Rocky repo’s but not yet ‘cleared’ by Nethesis? They have been available for a while.
dnf update --enablerepo=*
reason e.g. Rocky Linux Errata
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:
-
Immediate Transparency: Acknowledge that a critical upstream vulnerability exists.
-
Status Updates: Explain why the update is being held back (e.g., if it breaks core NethServer functionality).
-
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-baseosrestrictions, 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.
awaiting as of june 3rd, 2026
Install 5 Packages
Upgrade 192 Packages
Remove 5 Packages
Total download size: 302 M
I wonder if the Nethesis distributors/resellers (NethVoice users) are (made) aware of cve-2026-46227 . I use it freely, but was not made aware. And I doubled checked, May 28th was not a weekend nor out of Italian office hours.
A little ‘heads up’ would have been nice. Especially for a critical/essential company application. And more specifically when entities using NethVoice can read about the security issue in public and start asking questions.
I’d like to clarify a couple of points.
First, security communication and forum categorization are two different discussions. Even if we agree that certain security topics deserve visibility, that does not necessarily imply the need for a dedicated forum category.
My concern about a security category is not about withholding information behind a subscription. Security information is not something we compete on. The issue is that Rocky Linux, Red Hat, and other upstream projects already publish advisories and maintain dedicated discussion channels. Duplicating that work on our forum often adds effort without adding much value. The best security practice remains the same: keep systems up to date and monitor the relevant upstream sources.
Second, control of updates is always in the hands of the system administrator, with or without a subscription. The Nethesis-managed Rocky Linux repositories are enabled by default because updates can occasionally introduce regressions or service disruptions. This policy comes from years of operational experience, including situations many of us remember from CentOS 7 minor releases.
Administrators can temporarily or permanently override this behavior through DNF and repository configuration if they prefer to consume Rocky Linux updates directly. The project provides a default policy, but the final risk assessment and update strategy remain under the administrator’s control.
2 Likes
So we’re off-topic. 
I can split it if we need to move forward on first one
I understand that. But what does that mean in practice for Debian-based systems?
Basically, I should be on the safe side if I run a regular apt update && apt upgrade, shouldn’t I?
Yes. On Debian-based systems, a regular apt update && apt upgrade is sufficient to receive the available operating system updates, including security fixes.
Keep in mind that some updates may require additional actions to become effective. In particular, kernel updates require a system reboot.
I agree that we can improve the documentation around this topic, but the current update policy is already described in the manual: Operating system updates — NS8 documentation.
1 Like
but the CVE list is terrifyingly long…
CVEs
Security report based on the trixie release
*** New vulnerabilities
CVE-2026-3276 unicodedata.normalize() can take excessive CPU time…
https://security-tracker.debian.org/tracker/CVE-2026-3276
- libpython3.13-minimal, libpython3.13-stdlib, python3.13,
python3.13-minimal - libpython3.11-minimal, libpython3.11-stdlib, python3.11,
python3.11-minimal (obsolete)
CVE-2026-46245 In the Linux kernel, the following vulnerability has…
https://security-tracker.debian.org/tracker/CVE-2026-46245
- linux-libc-dev
CVE-2026-46252 In the Linux kernel, the following vulnerability has…
https://security-tracker.debian.org/tracker/CVE-2026-46252
- linux-libc-dev
Note that some packages were marked as obsolete. To deal with the
vulnerabilities in them, you need to remove them. Before you can do
this, you may have to upgrade other packages depending on them.
*** Vulnerabilities without updates
CVE-2013-7445 The Direct Rendering Manager (DRM) subsystem in the…
https://security-tracker.debian.org/tracker/CVE-2013-7445
- linux-libc-dev
CVE-2017-7475 Cairo version 1.15.4 is vulnerable to a NULL pointer…
https://security-tracker.debian.org/tracker/CVE-2017-7475
- libcairo2 (low urgency)
… 64929 characters…
Hence I said:
And here it becomes interesting. YOU, Nethesis, the community manager, The Vision and future.
What if YOU descide to take up an offer from another company?
June 4th,2026, still no updates from the @ns-baseos repo.
This is becoming a serious lack of confidence in Nethesis. How about NethSecurity, same deal, no updates, hijacked by Nethesis tempo/vision/discretion?
Now that is the best thing a ‘community manager’ can do. Ignore the most important topic at hand and cover it with a smiley, just to be present in the discussion. Jeezzzz
We are going off topic here.
There is an open issue currently blocking the upgrade to Rocky/AlmaLinux 9.8 because it can disrupt services:
The current trade-off is stability versus immediate adoption of the latest upstream updates. Until the issue is resolved, the default policy favors preventing service disruption.
Administrators who prefer a different trade-off remain free to upgrade to 9.8 and apply the required workaround.
On one hand makes sense: avoding service disruption with hassled updates. But this is in contrast with what you cited…
now…
In which part of administration manual is specified?
Operating system updates are demanded to the underlying Linux distribution.
There’s no mention that says “hey, after this command the repositories of your install will be disabled and the updates for RockyLinux are managed by our repositories”.
I know where this policy come from and I trust not only the project but also the company, however, without explicit declaration before the nethification of the install, could be perceived sketchy to say the least for the uninitiated. Gatekeeping works for me, as definition.
Development and documentation take for granted a lot of knowledge from who’s reading and installing.
Last but not least: a lot of installations, in my personal opinion, are there for having public accessible applications, like webmail and email servers, private cloud instances (like NextCloud) and some more… So lacking of some security patches both on system then on cluster overlord and last but not least on container installs could increase the attack surface and the risk for hostile actions.
I think we actually agree on the documentation aspect.
I’ve already acknowledged that the documentation can be improved. Missing information should not be interpreted as an attempt to hide something; more often it is simply information that the writer considered obvious, unimportant, or already covered elsewhere. When documentation is written from a developer’s perspective, some assumptions can remain implicit and leave unclear areas for readers approaching the project from a different background.
This forum is exactly the right place to raise those questions and highlight areas that deserve clarification. The documentation is also open to public contributions, so feedback and proposed improvements are always welcome.
At the moment, however, there is a concrete issue affecting the 9.8 upgrade path. Given limited resources, I think the priority should be to investigate and fix the bug, restore the normal update flow, and deliver the pending security updates. Improving the documentation is important too, but it should not delay resolving the underlying issue.
As for the update policy itself, there is no intention to remove control from administrators. The repositories and update behavior can be inspected, modified, or overridden at any time. The current defaults are the result of operational experience with updates that occasionally caused service disruptions, not an attempt to obscure how the system works.
3 Likes
I have an hunch that facts do not match this claim
This is not something last months, or trimester.
Yep, sometimes making smileys is the best thing to do. Keep your smile on your face sometimes (quote) 
But my sentence is still right, I need to split the topic because, as Davide mentioned, security communication and forum categorization are two different discussions
Sorry if I missed some of the points you raised. Some of them may also have been superseded by changes and new features over time.
If there are still documentation gaps or inaccuracies, please follow up in the original thread or open a new topic in the Bug category. Documentation bugs are bugs too, and they deserve to be tracked and discussed in the right place.
Since this topic is about forum categories, I’d rather not drift further into documentation issues here.
Who cares? Please address the topics at hand. Where are the updates from the NS repo’s and what is the so called ‘procedure’?
Please understand that it is not your job to descide on security policies of NS users/companies. Some of them can have a zero tolerance, but the Nethesis policy and non transparency and silence is not helping a lot. As a compnay I would not opt for Netheis products/services because of the lack of all this in a timely manner. Then again, I am not recognised as a digital hero.