future OpenWrt security support

[Etienne Champetier]

Hi Hauke, Jow,

Le sam. 3 oct. 2026 à 17:11, Hauke Mehrtens <hauke at hauke-m.de> a écrit :
>
> 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.

+1 to convert them as public issues.

Something that might help is having a SECURITY.md in each repo
describing when to use private reports and when to use public issues:

```
You MUST use public issues if:
- the security issue is already public
- fixing the issue just requires updating some packages or backporting
an already public patch
- the attack scenario requires physical access

You SHOULD use public issues if the security issue:
- is in a "niche" package
- involve "exotic" configuration
...
```

> > 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.

Having an old stable only gives ~1 year of extra life.

I had a look at my firmware archives,
I have a build of OpenWrt Backfire (r29520) for Bullet M2 from 2011-12-19,
and I'm now running OpenWrt 25.12 on some Bullet M2 XM (stripped down
config / no patches),
this is an extreme example but supporting a device for 15 years is
enough I think.

> 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.

If we announce that there will be no old stable during each RC,
hopefully this leads to more people testing the RCs and a .0 with no blockers.

Etienne

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