[civetweb] download instead of bundle, bump from 1.15 to 1.16, and define proper CMake target

[ferdymercury]

No description provided.

[github-actions]

Test Results

    22 files      22 suites   3d 13h 0m 11s ⏱️
 3 849 tests  3 846 ✅  1 💤 2 ❌
76 886 runs  76 862 ✅ 18 💤 6 ❌

For more details on these failures, see this check.

Results for commit be0cde1.

♻️ This comment has been updated with latest results.

[ferdymercury]

TO-DO: discuss if builtin_civetweb=OFF should be discouraged, by emitting a warning or better describing ROotBuildOptions text.

See discussion root-project/root-ci-images#110 (comment)

[ferdymercury]

@linev for Fedora we'd need root-project/root-ci-images#111

[ferdymercury]

TO-DO investigate

[ferdymercury]

@linev do you have a Mac where you could try out this PR ?

It's the only platform failing, with error:

fatal error: 'openssl/bn.h' file not found

Could you run locate bn.h to see if it exists.
If it does, then printing out what what the value of OPENSSL_INCLUDE_DIR is
If it doesn't maybe there is an option for builtin_openssl to install that header?

[ferdymercury]

Finally! Compilation failures on Mac solved, now builds on all platforms.
I guess this PR should be preceded by #22026

[ferdymercury]

@linev you mentioned that on some platforms the system-civetweb was not stable. Do you remember which platforms that was or how we can test the current status? Was it running a specific test? Do you remember exactly which ones?

I see opensuse having these flags:
https://code.opensuse.org/package/civetweb/blob/master/f/civetweb.spec

  | export CFLAGS="%optflags -DUSE_X_DOM_SOCKET"
-- | --
  |  
  | %cmake -DCIVETWEB_ENABLE_WEBSOCKETS=ON \
  | -DCIVETWEB_BUILD_TESTING=OFF \
  | -DCIVETWEB_ENABLE_CXX=ON \
  | -DCIVETWEB_ENABLE_SSL=ON \
  | -DCIVETWEB_SSL_OPENSSL_API_1_1=OFF \
  | -DCIVETWEB_SSL_OPENSSL_API_3_0=ON \
  | -DCIVETWEB_ENABLE_ZLIB=ON \
  | -DCIVETWEB_ENABLE_SSL_DYNAMIC_LOADING=OFF

and Debian here has some extra patches on 1.16

https://sources.debian.org/patches/civetweb/1.16+dfsg-4/

It looks like Debian 1.16 patches contain some fixes for DoS attacks and CVEs, so I think it would be beneficial if we switched to builtin_civetweb=OFF At least on the platforms where you are not aware of crashes.

[linev]

This was my attempt to make OpenSUSE package better.
But even with all necessary flags sometime it works (within particular OS build) and sometime does not.

This is main problem for me - even I think all necessary flags are provided something is still wrong.

[ferdymercury]

Thanks for the feedback.
How can I check eg if it's working stable on my local Ubuntu 22 if I build with builtin_civetweb=OFF ? And then running some tests? or just root --web=ON ?
If it works, then we could set builtin_civetweb OFF for Ubuntus and ON for opensuse ?

[linev]

How can I check eg if it's working stable on my local Ubuntu 22

It crashed when used with RBrowser or with simple THttpServer examples.
I also had report from user about similar failures on other platforms.

[ferdymercury]

I also had report from user about similar failures on other platforms.

Ok, thanks. What can be worrying is that users downloading the release binaries are (most of them unknowingly) using a builtin civetweb, even if they installed libcivetweb-dev.

There are known vulnerabilities in civetweb. Once the maintainer releases version 1.17, users having installed the system pacakge would (soonish) automatically get security updates for
https://nvd.nist.gov/vuln/detail/CVE-2025-55763
https://nvd.nist.gov/vuln/detail/CVE-2026-5789
civetweb/civetweb#1353

but ROOT 6.40 downloaded from binaries would still be (unknowingly) vulnerable for maybe a long time.

I also had report from user about similar failures on other platforms.

It could be useful if we document in the code or in a GH issue which platforms and what civetweb versions they were using to keep track of when this potentially gets solved. That way, we can then say find_package(civetweb 1.17) else use builtin.

In my opinion, we should also add patches from CVE vulnerabilities to the builtin version as soon as possible on top of this PR.