future OpenWrt security support

[Hauke Mehrtens]

On 10/3/26 21:59, Jo-Philipp Wich wrote:
> Hi Hauke,
> 
> I agree with the overall assessment, and would like to add a few
> observations about the reports themselves.
> 
> I have the feeling that a lot of the recent reports are primarily
> motivated by recognition or CVE attribution rather than by genuinely
> improving the project. In one instance a reporter publicly bragged about
> having found a root RCE, which turned out to be a weakness in
> luci-app-bmxd, a package that is rarely, if ever, installed. A lot of
> the reports target the restricted ubus ACL handling, which is not
> employed by default, and many of the presented vulnerabilities require
> various non-default packages and/or non-default settings to become
> exploitable at all. The result is that genuinely exploitable-by-default
> issues get swamped by "trivial" advisories.

Yes saw similar bug reports.

This for example is only possible when the luci-app-commands package is 
installed which is not by default and when it is strangely configured:
https://x.com/hackerfantastic/status/2074871544984064163

I started this PR: https://github.com/openwrt/luci/pull/8878
Would be nice if you could take it over. The report is in freescout.
> For LuCI I have seen basically identical advisories published by
> different persons at different times. From that I conclude that everyone
> with access to the current LLMs can find the same issues without any
> deeper expertise, and that any AI-found vulnerability can be
> rediscovered by any other interested party with roughly the same effort.
> For this class of issues the responsible disclosure process is
> essentially worthless: it needlessly ties up resources and forces us
> into the GHSA / CVE request / attribution dance that nobody has time for.
> 
> I would suggest we do not take security reports for non-default
> configurations too seriously. We should focus on fixing issues in the
> default configuration and issues that are likely to occur, e.g. in
> popular packages or commonly used settings. Concretely:
> 
> - Treat such reports as ordinary bug reports and simply fix them, rather
>    than going through the advisory process.
> - Encourage the creation of pull requests fixing the issues instead of
>    advisories.
> - Disable the GitHub security advisory reporting on our repositories, it
>    attracts drive-by bot traffic.

For real security reports the github process is pretty nice. It allows 
us to create private repos shared with the reporter and we can work 
together on the advisory.

I would prefer building a script which converts a github security 
advisory into a public issue. The script can close the github security 
advisory and link the public ticket. We can use it for these low 
severity reports you described.
> On shortening the support period: I understand this given the situation,
> and it is likely the only way forward, we cannot force volunteer work.
> 
> On the other hand, the OpenWrt system sees a lot of churn, frequently
> explicitly dropping or accidentally losing hardware support, leaving
> users in the rain with regard to security fixes.

Yes I agree that some people will have problems with it. Some people are 
still having problems with 25.12 and stay at 24.10. I think it should be 
fixed in 25.12 already, but it took some time.

We support ~1700 different devices and it is possible to configure them 
in a lot of different ways. This is hard to support.

Hauke