I’ve just got an Omnia, cool hardware, but it came with TOS 4. I’m disappointed to see that it appears you haven’t addressed CVE-2020-8597 in either TOS 4 or 5. Maybe I’m wrong, and you have backported mitigations to the version available in these (I’ve only seen it mentioned for 3). Could I get some clarity about this?
We haven’t released any Turris OS 4.0 since January and it was not fixed as you pointed out. We decided not to release Turris OS 4.0 anymore as they are breaking changes and this is not what we can push to users as some critical services do not start. Anyway, the CVE is already fixed in Turris OS 5.0.0. You might want to check it on this HBT build. 
Check, for example, this link https://repo.turris.cz/hbt/omnia/packages/git-hash and you can see which commits from each feed it uses.
Thanks for the prompt response. Are you absolutely sure that it’s fixed? Looking in /packages/base/ the ppp package has what appears to be the date 2019-05-25 on the end of it and afaia this was fixed only on 2020-02-03.
Also, does it not make sense to have security vulns updated shortly after there is a fix in any branch? I think this fix should be pretty unintrusive, not introducing a breaking change in and of itself.
12 posts were split to a new topic: Support of Turris OS branches
Yes, I am confident about that. You can check it here:
It was not fixed only on 2020-02-03, but related security fixes were cherry-picked as patches to previous releases. This is also why I suggested for you git-file on our repository to check it.
Alright, is there a policy for when vulnerabilities will get patched in future? I’m seeing that this is more of a DoS issue on OpenWRT due to compiler macros but I am curious about the ?ignoring? of 4.x before a 5.x is in stable. Maybe I’m just expecting something too much like a normal linux distro.
Thanks again.
Okay, that was bad. I tried a switch-branch hbt on my Omnia and bad things happened:
Wifi 1 stopped working
wan didn’t work some of the time. Sometime reboot fixed it.
ssh just didn’t work. It got to password prompt and then hangs
Switching back to hbs from luci seemed to work, but sshd still doesn’t get passed entering the password. Not being able to ssh to investigate issues is very limiting so I attempted a schnapps rollback to the pre-upgrade snapshot.
To your second point, I found the docs on your website. I had to go and get ssh set up as well cause LuCI commands won’t go through the whole flow automatically.
As for my experience so far with TOS 5:
Works fine.
I like some of the LuCI changes and dislike some others, probably most of this is not you guys.
Having some new behaviour with the PCI LEDs and I can’t see how that’s set, maybe I can’t see it because of preexisting configuration. I did like the fancy power up animation 
Do you have any thoughts on enabling WPA3 on default install?
Today, we are releasing a new RC of Turris OS 5.0.0 in the Testing branches.
We heard your voices that in some cases update was not smooth as it should be especially on Turris MOX routers. We worked on Updater, so it should take a less memory during the update. We removed sysgupgrade from the system. It is not available anymore as it is dangerous. We converted DHCP script to Python 3 and there is updated Knot Resolver to version 5.1.0. And we updated Sentinel DynFW, which addresses issue, which was mention here as well.
There are changes from feeds, which we are using, for example, updated wireguard, youtube-dl, fixed some issues with Cloudflare in ddns-scripts and added a new package - gerbera, which should be a replacement for MiniDLNA.
2 Likes
MOX update works, but device change MAC address again.
Have you solved the problem where the WiFi drivers fail to load with vmalloc error?
After upgrade the LUCI and Foris were not accessible. There seems to be missing python link to python3.
After running following commands, both working fine again.
ln -s /usr/bin/python3 /usr/bin/python
reboot
There is also a new topic here Luci inaccessible.
1 Like
Hi,
no the WiFi Probmel with the vmalloc is bigger in the new Version.
I can not load 6 kernel Driver.
Can i expand the vmalloc?
Blockquote
[ 16.763126] kmodloader: 6 modules could not be probed
[ 16.768230] kmodloader: dependency not loaded mac80211
[ 16.773455] kmodloader: - ath10k_core - 1
[ 16.777506] kmodloader: dependency not loaded ath10k_core
[ 16.783004] kmodloader: - ath10k_pci - 1
[ 16.786953] kmodloader: dependency not loaded mac80211
[ 16.792128] kmodloader: dependency not loaded ath9k_hw
[ 16.797316] kmodloader: dependency not loaded ath9k_common
[ 16.802887] kmodloader: - ath9k - 3
[ 16.806423] kmodloader: dependency not loaded ath9k_hw
[ 16.811619] kmodloader: - ath9k_common - 1
[ 16.815745] kmodloader: - ath9k_hw - 0
[ 16.819553] kmodloader: - mac80211 - 0
strange - for me the vmalloc is exactly the same as before, ath10k works but ath9k still gives the vmalloc error.
New problem (apart from the missing python resulting in foris and luci not working as described above) is luci_statistics stopped to work:
root@turris:~# /etc/init.d/luci_statistics restart
/usr/bin/lua: /usr/bin/stat-genconfig:37: attempt to index upvalue ‘sections’ (a boolean value)
stack traceback:
/usr/bin/stat-genconfig:37: in function ‘section’
/usr/bin/stat-genconfig:318: in main chunk
[C]: ?
This does not even work with the default file (copied luci_statistics-opkg to luci_statistics, same error)
Hi,
after update the Adblocker don’t work any more. kresd is running.
Blockquote
adblock-4.0.4[18014]: adblock instance started ::: action: start, priority: 0, pid: 18014
adblock-4.0.4[18014]: dns backend restart with adblock blocklist failed
kresd[31494]: [poli] RPZ /etc/kresd/adb_list.overall:3: RR type NS is not allowed in RPZ
The “not allowed” messages are just warnings, so I can’t see why it failed for you. (And in case of NS and SOA the warning is quite misleading; I’ll look into improving that.)
I have switched to hbt today. When trying to access luci, before login, I got:
/usr/lib/lua/luci/dispatcher.lua:426: /etc/config/luci seems to be corrupt, unable to find section 'main'
I have tried to restore /etc/config/luci to default without any change.
Maybe this one?
Indeed, this fixed it. Thanks.
I think @dibdot can help you with that, if you ask.