Turris OS and OpenWrt Feeds: Why Direct Upstream Integration Is Harder Than It Sounds
The Current Architecture
Turris OS is built directly on top of OpenWrt — TOS 9.x runs on OpenWrt 24.10. CZ.NIC maintains a separate os-packages repository that contains two categories of packages: things unique to Turris hardware and software, and backports or lightly-modified versions of packages that also exist in upstream OpenWrt. That second category is exactly what’s worth questioning.
Rebuilding packages that are functionally identical to upstream costs build time and delays fixes. When OpenWrt patches a vulnerability, Turris users don’t see it until CZ.NIC pulls the change, rebuilds, runs QA, and ships it through the updater. For security patches, that delay is a real concern.
What It Would Actually Take to Use OpenWrt Feeds Directly
The proposal, roughly: point the Turris updater at OpenWrt’s own feed URLs, keep a Turris-specific repo for hardware and custom packages, let priority rules handle conflicts. That’s how apt pinning works on Debian, how overlay repos work in many Linux distributions. Clean concept. But the Turris updater is not opkg, and several layers make this non-trivial.
Package Signing and the Trust Chain
This is the biggest blocker. The Turris updater uses usign for package signature validation. OpenWrt also uses usign — but with OpenWrt’s own keys, not Turris’s. To consume upstream packages directly, Turris would need to either trust OpenWrt’s public key in the updater (meaning devices accept packages CZ.NIC hasn’t reviewed or rebuilt) or re-sign every upstream package before serving it, which recreates much of the current pipeline.
Neither option is obviously correct. Trusting OpenWrt’s key directly is a supply-chain policy decision: you’re extending trust to whatever OpenWrt ships, at whatever cadence they ship it. Re-signing without rebuilding is technically an improvement — validate the binary, sign it, serve it — but it still requires automation infrastructure and raises the question of how you verify the OpenWrt binary matches its declared source.
A verified mirror is probably the most practical middle path: CZ.NIC validates and re-signs upstream packages on a set schedule, serving them from a Turris-controlled endpoint without rebuilding from source. This compresses the lag substantially while keeping the trust model intact. Some Linux distributions handle upstream packages this way.
Patches That Have Not Gone Upstream Yet
Some packages in Turris’s repository are modified versions of upstream OpenWrt packages — tweaked for Turris hardware, for specific feature requirements, or as temporary backports. CZ.NIC stores these as git-formatted patches in their build tree. If the updater consumed upstream binaries directly, every package with outstanding patches would need those merged upstream first, or would have to stay in the Turris repo permanently as a forced override.
CZ.NIC’s contributor documentation already encourages this approach: push Turris-specific fixes to OpenWrt first, and CZ.NIC picks them up in the next update cycle. That’s the right long-term behavior. But upstreaming a patch takes time — maintainer reviews, multi-architecture test builds, release scheduling. Until patches land, bypassing Turris’s build would silently drop those customizations.
The Updater’s Architecture
Turris uses its own package manager (updater-ng, also called pkgupdate) rather than standard opkg. It operates declaratively: Lua configuration scripts specify what packages should be installed, from which sources, at what trust level. Adding a new package source isn’t a one-line config change — it means defining the source in Lua, configuring trust levels, and wiring it into the list-generation step the build system produces alongside packages. Doable engineering, but it needs to ship without leaving devices with a broken updater state.
The Timing Problem
OpenWrt updates packages on its own cadence. If Turris devices pulled directly from live upstream feeds, a package update that broke something on Turris hardware could land before CZ.NIC noticed. The current rebuild process is slow, but it acts as a staging gate. Speed and safety are in tension here — though they can be separated.
The rebuild itself isn’t what provides safety. Testing does. A faster verification-and-resign loop gives most of the speed benefit without removing the safety layer. You can run compatibility checks against upstream binaries without building from source.
CZ.NIC’s Stated Philosophy Already Points This Direction
The Turris contributing documentation is explicit: for packages that originate from upstream OpenWrt, submit fixes to OpenWrt directly and CZ.NIC will pull them in on the next update cycle. Upstream-first is already the stated policy, not a new proposal.
TOS 9.x moving to OpenWrt 24.10 is a concrete step in this direction. Older TOS versions lagged further behind the OpenWrt release cycle; a tighter rebase schedule narrows the gap on its own, before any changes to feed architecture.
The remaining work to make direct upstream consumption viable is a defined engineering project: a re-signing pipeline with appropriate verification, updater-ng support for external trusted feed sources, and a systematic effort to upstream outstanding Turris-specific patches. Post-9.0 stabilization is a reasonable time to start scoping it — which is exactly what the forum post is suggesting.
