On Tue, Oct 25, 2022 at 7:37 AM Peter Naulls <pe...@chocky.org> wrote: > > On 10/24/22 18:21, Hauke Mehrtens wrote: > > Hauke, thanks for replying!
As I said on a related thread - if an eu body can be found to care more deeply on these issues, I'm pretty sure 30-50k of funding is available via one or more of nlnet's grant programs. Applications for this round close december 1st. https://nlnet.nl/ > > > > I also prefer if the CVE number is named in the patch. If this is missing > > somewhere you could send a patch or pull request to rename the patch. > > I'm afraid I don't have any explicit examples, but I'll let you know if > find any. There are some concerns with the older lua I mentioned below, > but I'll need to come back to those. In any case, a suggestion for future > CVE patches. > > > > > The OpenWrt project does not have enough resources to maintain security > > patches > > for the kernel on our own. OpenWrt relays on the LTS kernel maintenance and > > we > > update to the most recent LTS version every few days or weeks in the > > maintained > > branches. If some security patches are missing in the LTS kernel versions > > used > > by OpenWrt it is probably best to approach the Linux stable team directly. > > > > See this blog post from Greg Kroah-Hartman, especially the "Keeping a secure > > system" section: > > http://kroah.com/log/blog/2018/02/05/linux-kernel-release-model/ > > Yes, sure. And whether you or I agree with this or not is to some degree > irrelevant, since what matters to the security people is that they see > the bug fixed. In 90% of the cases I was able to dismiss CVEs > since the subsystems in question are not in use by us (or most of OpenWrt > for that matter. e.g, frame buffers), but some tricky ones remain. > > That said, there's a very large number of patches to the kernel in > OpenWrt; mostly for new device function, pending fixes or whatnot; > I guess few of these are actual security fixes. > > >> So, to user space: > >> > >> dnsmasq 2.86 - my pointing out that CVE-2021-45957 et al are false didn't > >> go > >> over particularly well, even though they have been properly dismissed by > >> the Simon Kelley and others. > > > > See my mail on the dnsmasq mailing list: > > https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2022q1/016161.html > > Yes, and was referred to and well understood by myself at least. Still, the > objection is that Mitre have this as "disputed", which is rather unhelpful, > and > that is what is being focused upon. Obviously I cannot fix something that > isn't > broken and has no fix, so there's no satisfactory answer here to a security > review beyond getting the CVEs dismissed from Mitre. > > > > > >> tcpdump 4.9.3 - CVE-2018-16303 > > > > This CVE is not for tcpdump, but PDF-XChange Editor: > > https://nvd.nist.gov/vuln/detail/CVE-2018-16303 > > Sorry, trying to juggle lots of items here. > > https://nvd.nist.gov/vuln/detail/CVE-2018-16301 > > > >> Long since in OpenWrt patches. > >> > >> e2fsprogs 1.46.5 - CVE-2022-1304 > > > > This is pretty hard to attack. You could provide a patch. > > This was the patch I provided here: > > >> > >> I brought in this patch: > >> > >> diff --git a/lib/ext2fs/extent.c b/lib/ext2fs/extent.c > >> index b324c7b0..1a206a16 100644 > > Yes, very large files on OpenWrt are unlikely without external > media. > > >> > >> If would be simply easier on the optics if I was able to ditch 5.1.5 in the > >> build and just use 5.3 - is this possible; I'm sure there's been much > >> discussion on this before, so please point me at that - will it break luci? > > > > An update to Lua 5.4 would be good, but I do not know which impact it has. > > Understood. I'm going to come back to this later in another post. > > > >> There's much more, but that's quite enough for now. > > > > OpenWrt is a mostly volunteer run project. Especially (security) maintenance > > does not get paid by companies. If you have some fixes tested patches would > > be > > really helpful. > > Yes, I know, and to say my reliance upon OpenWrt over the years is > considerable > would be an understatement, but my time is limited as well, and my focus > must be on addressing specifics to the security review. Still, I felt it > better to at least have a partial discussion here, and do what little I can. > > I don't necessarily have time to roll patches in a format suitable > for OpenWrt upstreaming; sometimes I think it's more constructive to simply > point out what can be done, and have the maintainers do it. Maybe not ideal, > but it's something. > > Look for some more posts on specific topics in the near future. > > > > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- This song goes out to all the folk that thought Stadia would work: https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz Dave Täht CEO, TekLibre, LLC _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel