Remove eMudhra and Sectigo/Comodo AAA root certificates
Address several Linux potential skb vulnerabilites, including ZDI-CAN-33367
This update is being rolled out now. You can manually initiate the upgrade if you’d like, or it will automatically update overnight (if auto-updates are enabled). The complete, up-to-date changelog is available here:
If you have questions, feedback, or run into any issues, feel free to reply here or start a new topic. Including configuration details or relevant logs where possible helps us troubleshoot and respond more quickly.
On 1.5k and 1.5l with Tailscale enabled, the router re-runs its whole config apply every minute (rc: Re-running dl cfg, ~1,440 times a day). 1.5k’s /etc/opkg/alta-pkg.conf points at pkg/10/netbird/0.80.0-1, which returns 403 (0.78.1-1 still returns 200). So apkg update fails, cfg never reaches touch /var/run/cfg-dl.ready, and rc retries 60 s later. Each pass reinstalls and reloads Tailscale and rewrites its advertised routes. On a stock setup that’s mostly log noise, but any route added outside the portal is wiped every minute, and every tailnet device reconfigures its tunnel each time. Writing apkg’s stamp file by hand stopped it on the next pass, which confirms the cause. Could you publish the 0.80.0-1 feed, or not let a failed apkg update block the rest of the apply?
@antonioacg Could I get an invite to your site where this is happening? I’m not able to reproduce. Sounds like you have both tailscale and netbird enabled. Do you have any firewall blocking in place? We’ve re-published 0.80.0-1 just in case and if you want to check again.
@austin.payne Thanks, and sorry for the slow reply. The re-publish fixed it: 0.80.0-1 returns 200, apkg update succeeds at boot (on 1.5m and now 1.5n), and the every-minute re-apply hasn’t come back, so no invite needed.
To answer your questions for the record: NetBird was never enabled, only Tailscale. The netbird feed is listed in alta-pkg.conf either way, so apkg update failed even with NetBird off. And no firewall was in the way: the 403 was the server’s own HTTP response, and the same host returned 200 for 0.78.1-1 at the same time.