Re: [OE-core][scarthgap 1/8] libmicrohttpd: fix CVE-2025-59777, CVE-2025-62689

[Changqing Li <changqing.li@windriver.com>]

[-- Attachment #1: Type: text/plain, Size: 2701 bytes --]


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

[-- Attachment #2: Type: text/html, Size: 3839 bytes --]