TOS 3 and 4 are vulnerable. Use TOS 5 (HBT) instead.
Turris OS 3.x is not vulnerable! It was backported it there. You can check it. 
I appreciate your work, I guess I’m just confused by the difference between how 3.x is treated vs the most current. Is it that 3.x gets LTS and 4.x is EOL? If that’s the case maybe it should be noted somewhere?
Seeing your edits I’ll put in mine:
I’m not really git fluent so the hashes don’t help me figure out what’s happening. I can follow a human readable version number much easier. I’m figuring out how to move to HBT right now and I’ll get that going.
Well, yes, support for 3.x happens to be longer than support for 4.x. My personal point of view is that 3->4 migration is harder than 4->5 and maintaining two branches seems enough work, so this “irregularity” makes sense to me.
From 4.x it’s just a simple command switch-branch hbt (but see the initial post of this thread anyway)
I think that in general not supporting multiple branches makes sense, definitely decreases the load on you folks, but, honestly and humbly, I think that since 4.x ships on some of the routers the right thing to do is patch that until 5.x is ready to move to HBS. If that’s not feasible maybe notice of deprecation and a downgrade to 3 would have made sense? A big part of the marketing I saw was that one always has the latest security patches with Turris OS on auto update.
2 Likes
Most likely not. For example, 3.x never got MOX support, IIRC.
TOS 3 is obsolete, TOS 4 is unsupported and TOS 5 was not released. OpenWrt 19.07 (on which the TOS 5 builds) will be EOL in January 2021.
1 Like
openwrt is developing viktor, to the next version, and so will TOS. may i suggest you sell your Omnia/whatever, and get some big brand router with a big support forum. There you can tell everyone whats is wrong with it. Or, even beter , build your own. Call it genius V1, and have your name printed on it.
5 Likes
And why do you think I should do it?
Depends on particular person. IMO it’s like saying that RHEL 7 is obsolete.
There is a bit of a difference though, with RHEL having a clear defined lifecycle (production phases + ELP) which is not apparent/documented for TOS3.x. The underlying OpenWrt version has reached EoL some time ago.
As for TOS4.x there is neither a clear defined lifecycle, only some mention that development ceased and some reference that the underlying OpenWrt version is has reached EoL as of this month.
2 Likes
RHEL 7 is still supported (same as very old and useable RHEL 6). OpenWrt 15.05 is unsupported and in many cases you have written that you cannot pay attention to TOS 3.
I do consider 3.x supported; they’re still getting security patches ATM. My family is using two Omnias on 3.x (no need for fresh features in that case).
I split the related discussion into a separate thread, as I think many followers of the original thread aren’t interested in it.
1 Like
Are you meaning that newer kernel (or userland or libraries) are only about new features and nothing about security or that kernel (or userland or libraries) in TOS3.x provide the same level of security as newer OS code?
(My personal opinion.) Probably not as good level of security, but still quite good. I don’t know details about TOS 3.x, but in general longterm branches in Linux distros are used even in quite security-demanding places. It’s also not one-way… new versions tend to have higher likelihood of security regressions than adding just security patches, so with longterm branches you have neither subset nor superset of (security) bugs.
I have got no data about which distros are deployed in such environment, therefore content with your assessment
that TOS3.x suffices.
As an example, I think RHEL/CentOS get commonly put on places that are more risky than Turris, but I can’t say I really have data about that (and the thoroughness of patching etc. can’t be compared between these two, of course).
I fully agree. I am also using Omnia with TOS 3 as main router at many destinations.
I am using CentOS 15+ years contentedly.
Rephrasing what I’ve said earlier:
I think the dropping of 4.x before 5.x is in stable was a slight misstep, but these things happen and it’s good that you are open about it.
The only place where I see a continuing issue is in clarity around support. As @anon82920800 pointed out the difference is that RHEL versions have clearly defined support duration and get fixes for the entire duration. Now, I understand you probably don’t have quite the same wealth of engineering man hours that RedHat do so I don’t expect LTS on many versions but I think dealing with the clarity is definitely in scope for you.
Again, I do appreciate the device and your work on it.
1 Like