Just after updating to 26.4_6 the security audit produces a list of 7 vulnerabilities with CVE. Is this the new normal now that AI is searching for them?
This is not meant to discredit the OPNsense maintainers, just a general question. I just want to be prepared for a time when running a firewall with known vulnerabilities is the new normal.
Welcome to 2026.
Most of it is Python. According to https://peps.python.org/pep-0719/ 3.13.14 will be out by Tuesday, 2026-06-09.
In the meantime we'd have to put in a lot of effort to micro manage Python fixes and potentially clashing with similar efforts in FreeBSD ports. It's not a good option for us at the moment with the priorities we have.
So, yes, 2026. Welcome to the future.
Cheers,
Franco
PS: OpenVPN 2.6.20 is not vulnerable. The FreeBSD ports database is wrong but since they skipped the version there's no effort there to be more diligent.
Quote from: franco on May 06, 2026, 05:26:48 PMMost of it is Python. According to https://peps.python.org/pep-0719/ 3.13.14 will be out by Tuesday, 2026-06-09.
In the meantime we'd have to put in a lot of effort to micro manage Python fixes and potentially clashing with similar efforts in FreeBSD ports. It's not a good option for us at the moment with the priorities we have.
So, yes, 2026. Welcome to the future.
Does that future include kicking out that weird snake at some point ?? :P
Quote from: nero355 on May 07, 2026, 12:00:47 AMDoes that future include kicking out that weird snake at some point ?? :P
There's nothing to kick.
So many things depend on python is not even funny. And the goal is to be on a supported version that can be used with everything that depends on it.
FWIW, FreeBSD 14.x branch is still lagging on python311 while OPNsense was able to jump on the python313 train shortly after 26.1 —- which in turn caused issues on the mimugmail repo with things not building properly.
Thankfully it would appear some if not all of the mimugmail issues have been ironed out as I just found today a new Unifi update along with the associated dependencies.
Yep, looking at the current open source ecosystem Python isn't going anywhere in many projects. We're also using it in backend scripting.
Cheers,
Franco
Quote from: newsense on May 07, 2026, 05:36:57 AMQuote from: nero355 on May 07, 2026, 12:00:47 AMDoes that future include kicking out that weird snake at some point ?? :P
There's nothing to kick.
So many things depend on python is not even funny. And the goal is to be on a supported version that can be used with everything that depends on it.
Quote from: franco on May 07, 2026, 10:10:06 AMYep, looking at the current open source ecosystem Python isn't going anywhere in many projects.
We're also using it in backend scripting.
I will keep dreaming of a Python-free World then :)
As long as there are no snakes on a plane I guess we're fine.
Cheers,
Franco
CMK is still reporting python313 as vulnerable since months in all my opnsense-instances. Is there any action to do? When will this warning disappear?
Do you mean this one?
root@opnsense:~ # pkg audit
python313-3.13.15 is vulnerable:
Python -- poplib module, when passed a user-controlled command, can have additional commands injected using newlines
CVE: CVE-2025-15367
WWW: https://vuxml.FreeBSD.org/freebsd/6d3488ae-2e0f-11f1-88c7-00a098b42aeb.html
I am pretty sure OPNsense does not use POP3 anywhere. So that does not apply.
Word on the street is that this issue was not backported to 3.13.x and others for fear of regressions. 3.15 is the first fixed Python release with the fix. It gives you a bit of scope regarding the severity of the issue for existing installations discarding the fact that it is about POP3 as Patrick noted.
Cheers,
Franco
Hey franco, hey Patrick,
thanks for your replies. If I understood correctly, the warning will disappear, as soon as python3.15 is used with OPNsense. Are there any plans on that?
Don´t get me wrong: As long as there is no real security issue, everything is fine. But I would be happy, when one day the warning in CMK will disappear to focus on the real CVE-issue(s). At the moment it is kind of false positive :(
Ok, one hour ago the warning in CMK disappeared. Weird :P
> pkg: unable to open vulnxml file (null): Invalid argument (mapping with zero length)
FreeBSD's database file was broken by what looks like partial or faulty upload. We've been debating hosting the file ourselves and just decided we're going to do that, but it will take a bit more time to do that since the URL needs to be changed in the pkg repository (yes it can be overwritten in pkg.conf but we don't want to operate pkg.conf for other reasons).
Cheers,
Franco
Yes yesterday evening the warning appeared again. Does it have any changes on the functionality of the database if you host the file by yourself?
@franco: Are there any plans to level python up to 3.15?
> Are there any plans to level python up to 3.15
In a world flooded by AI emergencies-likely some things will have to change.
Beginning of the year and prior 3.11 was more or less abandonware upstream although still very much the default in Fbsd 14.x and theoretically supported upstream.
Things got so bad that a move mid release was necessary. So shortly after 26.1 we moved on to 3.13.
Why 3.13 ? Iirc things weren't much better with 3.12 and unusable with 3.14 which is still the latest stable version until 3.15 is officially available.
So I'm expecting 3.15 to be available as soon as possible - meaning that everything depending on it can be built and works correctly. Whether that's going to be an easy job or a waiting game where all the upstream projects adjust for 3.15 and the changes it brings remains to be seen.
That's how I remember it watching from the sidelines.
FreeBSD is still on 3.12. We might consider going forward when FreeBSD is on 3.13. The ports tree is not overly reliable for versions newer than the FreeBSD default version so making smaller steps when FreeBSD has caught up seems best.
What newsense said also applies. We mainly moved to 3.13 for a bit of performance gains (and had to jump through a few hoops to build all ports correctly).
Cheers,
Franco