| Message ID | cover.1764713862.git.steve@sakoman.com |
|---|---|
| State | Not Applicable, archived |
| Delegated to: | Steve Sakoman |
| Headers | show |
On Wed, Dec 3, 2025 at 12:25 AM Gyorgy Sarvari <skandigraun@gmail.com> wrote: > > This is quite a big change in the middle of an LTS release... not that I > have a better solution. But maybe a warning in the docs would be > appropriate about this removed feature and its reason (not sure who > takes care of these). You are quite correct, this is a large change and deserves further discussion since it is removing a (admittedly experimental) feature. I will remove this from this series pending further discussion on list. Steve
On 12/5/25 01:59, Steve Sakoman wrote: > CAUTION: This email comes from a non Wind River email account! > Do not click links or open attachments unless you recognize the sender and know the content is safe. > > On Wed, Dec 3, 2025 at 12:25 AM Gyorgy Sarvari<skandigraun@gmail.com> wrote: >> This is quite a big change in the middle of an LTS release... not that I >> have a better solution. But maybe a warning in the docs would be >> appropriate about this removed feature and its reason (not sure who >> takes care of these). > You are quite correct, this is a large change and deserves further > discussion since it is removing a (admittedly experimental) feature. > > I will remove this from this series pending further discussion on list. Hi, This vulnerability exists in libmicrohttpd_ws.so, which is generated when building with the --enable-experimental option, rather than in widely used libmicrohttpd.so. We don't enable this option by default, also we don't provide PACKAGECONFIG for it. How about we still keep the patch for fixing CVE-2025-59777, CVE-2025-62689, and add the following warning in libmicrohttpd_1.0.2.bb +python do_warn_experimental() { + if '--enable-experimental' in d.getVar('EXTRA_OECONF') and '0001-Remove-broken-experimental-code.patch' in d.getVar('SRC_URI'): + bb.warn("This option is removed for CVE-2025-59777, CVE-2025-62689, if you insist to use it, please remove patch 0001-Remove-broken-experimental-code.patch") +} +addtask warn_experimental before do_configure + if the user enable '--enable-experimental' , warning is it removed. if user insist to use it, they can remove patch 0001-Remove-broken-experimental-code.patch locally, then warning will disappear. //changqing > > Steve
On Fri, Dec 5, 2025 at 8:22 AM Changqing Li via lists.openembedded.org <changqing.li=windriver.com@lists.openembedded.org> wrote: > > > On 12/5/25 01:59, Steve Sakoman wrote: > > CAUTION: This email comes from a non Wind River email account! > Do not click links or open attachments unless you recognize the sender and know the content is safe. > > On Wed, Dec 3, 2025 at 12:25 AM Gyorgy Sarvari <skandigraun@gmail.com> wrote: > > This is quite a big change in the middle of an LTS release... not that I > have a better solution. But maybe a warning in the docs would be > appropriate about this removed feature and its reason (not sure who > takes care of these). > > You are quite correct, this is a large change and deserves further > discussion since it is removing a (admittedly experimental) feature. > > I will remove this from this series pending further discussion on list. > > Hi, > > This vulnerability exists in libmicrohttpd_ws.so, which is generated when building with the --enable-experimental option, rather than in widely used libmicrohttpd.so. > > We don't enable this option by default, also we don't provide PACKAGECONFIG for it. > > How about we still keep the patch for fixing CVE-2025-59777, CVE-2025-62689, and add the following warning in libmicrohttpd_1.0.2.bb > > +python do_warn_experimental() { > + if '--enable-experimental' in d.getVar('EXTRA_OECONF') and '0001-Remove-broken-experimental-code.patch' in d.getVar('SRC_URI'): > + bb.warn("This option is removed for CVE-2025-59777, CVE-2025-62689, if you insist to use it, please remove patch 0001-Remove-broken-experimental-code.patch") > +} > +addtask warn_experimental before do_configure > + > > if the user enable '--enable-experimental' , warning is it removed. if user insist to use it, they can remove patch 0001-Remove-broken-experimental-code.patch locally, then > > warning will disappear. I think it should be the other way around. If we don't enable the option and don't have a tunable PACKAGECONFIG for it, why complicate and patch? If someone did enable it knowingly, they should fix it in their append or recipe. Thanks, Anuj
On 12/5/25 11:41, Anuj Mittal wrote: > CAUTION: This email comes from a non Wind River email account! > Do not click links or open attachments unless you recognize the sender and know the content is safe. > > On Fri, Dec 5, 2025 at 8:22 AM Changqing Li via lists.openembedded.org > <changqing.li=windriver.com@lists.openembedded.org> wrote: >> >> On 12/5/25 01:59, Steve Sakoman wrote: >> >> CAUTION: This email comes from a non Wind River email account! >> Do not click links or open attachments unless you recognize the sender and know the content is safe. >> >> On Wed, Dec 3, 2025 at 12:25 AM Gyorgy Sarvari<skandigraun@gmail.com> wrote: >> >> This is quite a big change in the middle of an LTS release... not that I >> have a better solution. But maybe a warning in the docs would be >> appropriate about this removed feature and its reason (not sure who >> takes care of these). >> >> You are quite correct, this is a large change and deserves further >> discussion since it is removing a (admittedly experimental) feature. >> >> I will remove this from this series pending further discussion on list. >> >> Hi, >> >> This vulnerability exists in libmicrohttpd_ws.so, which is generated when building with the --enable-experimental option, rather than in widely used libmicrohttpd.so. >> >> We don't enable this option by default, also we don't provide PACKAGECONFIG for it. >> >> How about we still keep the patch for fixing CVE-2025-59777, CVE-2025-62689, and add the following warning in libmicrohttpd_1.0.2.bb >> >> +python do_warn_experimental() { >> + if '--enable-experimental' in d.getVar('EXTRA_OECONF') and '0001-Remove-broken-experimental-code.patch' in d.getVar('SRC_URI'): >> + bb.warn("This option is removed for CVE-2025-59777, CVE-2025-62689, if you insist to use it, please remove patch 0001-Remove-broken-experimental-code.patch") >> +} >> +addtask warn_experimental before do_configure >> + >> >> if the user enable '--enable-experimental' , warning is it removed. if user insist to use it, they can remove patch 0001-Remove-broken-experimental-code.patch locally, then >> >> warning will disappear. > I think it should be the other way around. If we don't enable the > option and don't have a tunable PACKAGECONFIG for it, why complicate > and patch? If someone did enable it knowingly, they should fix it in > their append or recipe. if we don't patch it, should we add function like do_warn_experimental to remind user about the CVE? it is possible that user enable experimental, but they don't know the existence of CVE-2025-59777, CVE-2025-62689. Thanks //Changqing > Thanks, > > Anuj