Are you really sure that current kernel is not vulnerable?
Kernel is not vulnerable against what?
Security issues related to Omnia (4.4.199 X 4.4.212).
Which security issues?
It is just question.
And here we go again. That’s why I was curious, what you are trying to point out.
This forum thread is for Turris OS 3.11.14, where are updated three packages: opkg, wireguard and youtube. If you would like to have an updated kernel, oh… I almost forgot! You have already asked about it, don’t you? Also, I know that you are active when looking for contributions that are done in the Turris OS 3.x series. You already know that for some people, there is an issue and I don’t have anything why don’t admit it as we are open-source project, when using kernel version >= 4.4.200, which I am not able to reproduce and it was pointed by you in Turris OS 3.11.13 thread.
According to what you are trying to say that we shouldn’t release a version, where is fixed security vulnerability in opkg and let’s leave it as it is and left it to one of that larger releases, where will be also included kernel version with many things, right? I’d like to apologize, but this is not how it works. We are fixing security vulnerabilities, when we are aware of them and release it to owners of Turris routers to protect them. Already one guy on IRC Freenode turris asked me if we are aware of it and if his router is protected for this vulnerability. I would need to repeat my colleague, who responded to you in one of the Czech thread and said to you: “Based on your post, we are not able to maintain stability of releases and you want to update kernel right away, but fixing security vulnerabilities and updating packages goes hand by hand with stability.” Kernel update will be when its time.
By using the search function on this forum, you can see that you are asking repeatedly for the same things. Maybe you might want to try Turris OS 4.0.5 and then you can start asking OpenWrt developers when they would like to update kernel as kernel among other things is managed by them. 
4 Likes
Thank you for decomposition. Do you know about any security issue related with Turris Omnia, Turris OS 3.x and kernel version 4.4.199?
To the point of OpenWrt developers and kernel 4.14: I’m going to write to them regarding the backport of SFP drivers.
Can anybody from Turris team answer?
On another device I’m using OpenWrt with Linux 4.19.102. They are different choices. Surely here we do not go on with the versions for a valid reason. The most updated version is not always the best.
1 Like
Is this kernel compatible with Omnia?
There is an image of OpenWrt for Omnia too, but I don’t know how to bring the kernel into Turris OS. I don’t think it’s possible without a tremendous effort. Moreover, OpenWrt for Omnia does not support several things (in addition to those of the screenshot, the 8 GB disk is also a problem). So you either change your device or you are satisfied or you become a good home programmer.
TOS6.x with kernel 4.19.93 is available, least as medkit [1] but probably not through switching branches any more since the developers decided to remove it from the workflow and thus the build bot queue (last build date been JAN 13 '20). Foris does not work in that version.
Unfortunately the TOS development status is back where it was 2 years ago:
- development resources remain scarce (least what transpires publicly)
- obsolete TOS3.x (basedLEDE 15.05 (Chaos Calmer)) is being dragged on, wasting precious development resources
- TOS4.x (OpenWrt 18.06.x based) is outlived already by OpenWrt 19.07.x, thus also wasting precious development resources
- TOS5.x (based on current OpenWrt 19.07.x) not being released
- TOS6.x (based on OpenWrt Master) been stopped, supposedly it wasted precious development resources that could better be wasted somewhere else instead (like file server apps and TOS3.x)
- hardware related development support for the TO platform is stalled, basically since the inception of MOX (and its inherent issues)
When the first alpha versions of TOS4.x appeared about a year ago there has been hope that the core OS development would finally be able to regain pace with OpenWrt development but unfortunately the situation now is not only being a deja-vu but getting worse even.
2 Likes
The fact is, as someone reminded me, that we are not facing an enthusiastic community or a non-profit organization. We are facing a company, created by enthusiasts, perhaps, but which lives on itself and needs to earn money and money to survive. This has several consequences:
- the choices of the company should not be questioned; in fact where there is a community, there is sharing or division, but everything remains in everyone’s hands; here there is a monolith that advances and is a community within itself and perhaps not even (I suppose there are more rigid hierarchies than those that can be created spontaneously in a community). It only creates an illusory effect, because it is an open source project published on GitLab. But although the code is public, the underlying ideas are not common.
- being that a society requires seriousness for profit, the dynamics are different from the community. The latter has rules that are created by themselves from time to time, who is capable contributes and although there is a common idea, there is much more vitality and the ways to go are always different and mistakes are made bigger discoveries . On the contrary, a company has strict rules, needs to feed its mouths and tries to keep things as stable as possible, to have a good to sell and to have as few problems as possible; whether it succeeds or not is another matter. The forum is another problem, because it arises, as publicly declared, to make users communicate and help each other in particular scenarios, sharing their experience, but also here as for the source code, it always creates an illusory opening effect, which does not is and cannot be there. Of course all this generates unnecessary frustrations, because many users start from wrong assumptions.
- the contributions of the users are also different: while in a community project, you experiment and get what you want, here you cannot change a company vision and the maximum of the external contribution in code is related to corrections, which lighten the work of company employees.
In conclusion, this is a product with a brand, as there are millions of them in the world of technology and products; those who like it will buy it, use it, keep it and advise it; for those who do not find it the maximum will not buy it, will not keep it, will sell it and will not recommend it to others. This freedom should still be guaranteed. But the complaints here, in which I too have fallen too many, do not make sense, because they do not lead to any kind of change.
You are my hero. What is the purpose of continuing to publish these links to GitHub (I have seen similar links scattered all over the forum)? What usefulness for the forum? What would you like to communicate to all of us?
5 Likes
This thread is about “Kernel in Turris OS 3.x series”.
Do you keep users up to date on various kernel changes? Can’t we see them directly from the source? Like a newsletter or newsfeed?
Not everything is bad as it seems you know. On the other hand it is nice to say that “obsolete TOS3.x is being dragged on, wasting precious development resources” but you are completely missing context. We are not here to just serve top users. We are here to server all users and there are blockers why we can’t just drop TOS 3.x as well as to release 5.x right now.
We can’t drop Turris OS 3.x because there are about Turris 1.x routers still using that are not fully supported on Turris OS 4.0+ and most notably we have to still improve migration process to be able to migrate them. The reason is that Turris OS 4.0+ contains tweaks we did to support Turris Mox with big storage but less memory while Turris 1.x is completely opposite beast and without increased storage space it fails to update. It is just not about Turris Omnia you see. Nothing is as easy as it might seem.
At the same time we want to release TOS 5.0 but that is not easy either. OpenWrt upstream broke init scripts and they on top of that also backported that “fix” to OpenWrt 18.06 so we can’t release new version based on latest upstream for Turris OS 4.x either.
I really don’t know what you expect from us @anon50890781. Release every week and every few months new module for Mox and every year new router? Oh I know you want your master builds. I know that you want them and we have issue for that. https://gitlab.labs.nic.cz/turris/turris-build/issues/108
You know it is not about satisfying you (as I already stated multiple times). It is about satisfying all users and trust me only few cares about latest build from master. What they care about is that services they expect to work do work and that is our priority at the moment. They care that we can migrate them to latest version once that is ready. That is our job. Just because we are not working on issues you consider priority does not mean that we are bad and ugly company. We are group of enthusiasts but we have just different view on project priorities than you. You have to accept that.
6 Likes
It simply boils down to the fact that the developer resources are insufficient to support the vendor platforms in a somewhat timely fashion:
- one year on from the alpha release of TOS4.x (save 4 months after the release of TOS4.0)
- migration script not ready
- Turris 1.x platform support not finished
and that is now being the reason that TOS3.x is being dragged on… In for another year then? Oh forgot, no roadmap, it is ready when it is ready - so maybe another two years then (reading tea leafs).
Notwithstanding, hardware development for other platforms than the MOX being stalled with development resources dedicated to sort the multitude of issues of the MOX platform.
One could only hope not seeing that there are apparently insufficient development resources to even support the current platforms.
Cannot help it but prefer to look forward and if all the other users are perfectly happy to be served obsolete code instead, which TOS3.x for sure is.
And yet despite that TOS4.x is released and TOS5.x is not (nowhere near release), both with the same kernel and the some breakage, thus that reasoning seems moot really.
Where is the bug tracked/referenced with OpenWrt, if you do not mind asking?
Or are you ominously referring to [2]? Which been sorted in HBD one week ago, has it not? Why sticking with TOS4.x instead of getting on with releasing TOS5.x?
Quite the (paying) customer oriented attitude.
1 Like