When building WebKitGTK+, it’s a good idea to stick to the default values for the build options. If you’re building some sort of embedded system and really know what you’re doing, then OK, it might make sense to change some settings and disable some stuff. But Linux distros are generally well-advised to stick to the defaults to avoid creating problems for users.
One exception is if you need to disable certain features to avoid newer dependencies when building WebKit for older systems. For example, Ubuntu 18.04 disables web fonts (ENABLE_WOFF2=OFF) because it doesn’t have the libbrotli and libwoff2 dependencies that are required for that feature to work, hence some webpages will display using subpar fonts. And distributions shipping older versions of GStreamer will need to disable the ENABLE_MEDIA_SOURCE option (which is missing from the below feature list by mistake), since that requires the very latest GStreamer to work.
Other exceptions are the ENABLE_GTKDOC and ENABLE_MINIBROWSER settings, which distros do want. ENABLE_GTKDOC is disabled by default because it’s slow to build, and ENABLE_MINIBROWSER because, well, actually I don’t know why, you always want that one and it’s just annoying to find it’s not built.
OK, but really now, other than those exceptions, you should probably leave the defaults alone.
The feature list that prints when building WebKitGTK+ looks like this:
-- ENABLE_ACCELERATED_2D_CANVAS .......... OFF -- ENABLE_DRAG_SUPPORT ON -- ENABLE_GEOLOCATION .................... ON -- ENABLE_GLES2 OFF -- ENABLE_GTKDOC ......................... OFF -- ENABLE_ICONDATABASE ON -- ENABLE_INTROSPECTION .................. ON -- ENABLE_JIT ON -- ENABLE_MINIBROWSER .................... OFF -- ENABLE_OPENGL ON -- ENABLE_PLUGIN_PROCESS_GTK2 ............ ON -- ENABLE_QUARTZ_TARGET OFF -- ENABLE_SAMPLING_PROFILER .............. ON -- ENABLE_SPELLCHECK ON -- ENABLE_TOUCH_EVENTS ................... ON -- ENABLE_VIDEO ON -- ENABLE_WAYLAND_TARGET ................. ON -- ENABLE_WEBDRIVER ON -- ENABLE_WEB_AUDIO ...................... ON -- ENABLE_WEB_CRYPTO ON -- ENABLE_X11_TARGET ..................... ON -- USE_LIBHYPHEN ON -- USE_LIBNOTIFY ......................... ON -- USE_LIBSECRET ON -- USE_SYSTEM_MALLOC ..................... OFF -- USE_WOFF2 ON
And, asides from the exceptions noted above, those are probably the options you want to ship with.
Why are some things disabled by default? ENABLE_ACCELERATED_2D_CANVAS is OFF by default because it is experimental (i.e. not great :) and requires CairoGL, which has been available in most distributions for about half a decade now, but still hasn’t reached Debian yet, because the Debian developers know that the Cairo developers consider CarioGL experimental (i.e. not great!). Many of our developers use Debian, and we’re not keen on having two separate sets of canvas bugs depending on whether you’re using Debian or not, so best keep this off for now. ENABLE_GLES2 switches you from desktop GL to GLES, which is maybe needed for embedded systems with crap proprietary graphics drivers, but certainly not what you want when building for a general-purpose distribution with mesa. Then ENABLE_QUARTZ_TARGET is for building on macOS, not for Linux. And then we come to USE_SYSTEM_MALLOC.
USE_SYSTEM_MALLOC disables WebKit’s bmalloc memory allocator (“fast malloc”) in favor of glibc malloc. bmalloc is performance-optimized for macOS, and I’m uncertain how its performance compares to glibc malloc on Linux. Doesn’t matter really, because bmalloc contains important heap security features that will be disabled if you switch to glibc malloc, and that’s all you need to know to decide which one to use. If you disable bmalloc, you lose the Gigacage, isolated heaps, heap subspaces, etc. I don’t pretend to understand how any of those things work, so I’ll just refer you to this explanation by Sam Brown, who sounds like he knows what he’s talking about. The point is that, if an attacker has found a memory vulnerability in WebKit, these heap security features make it much harder to exploit and take control of users’ computers, and you don’t want them turned off.
USE_SYSTEM_MALLOC is currently enabled (bad!) in openSUSE and SUSE Linux Enterprise 15, presumably because when the Gigacage was originally introduced, it crashed immediately for users who set address space (virtual memory allocation) limits. Gigacage works by allocating a huge address space to reduce the chances that an attacker can find pointers within that space, similar to ASLR, so limiting the size of the address space prevents Gigacage from working. At first we thought it made more sense to crash than to allow a security feature to silently fail, but we got a bunch of complaints from users who use ulimit to limit the address space used by processes, and also from users who disable overcommit (which is required for Gigacage to allocate ludicrous amounts of address space), and so nowadays we just silently disable Gigacage instead if enough address space for it cannot be allocated. So hopefully there’s no longer any reason to disable this important security feature at build time! Distributions should be building with the default USE_SYSTEM_MALLOC=OFF.
The openSUSE CMake line currently looks like this:
%cmake \
-DCMAKE_BUILD_TYPE=Release \
-DLIBEXEC_INSTALL_DIR=%{_libexecdir}/libwebkit2gtk%{_wk2sover} \
-DPORT=GTK \
%if 0%{?suse_version} == 1315
-DCMAKE_C_COMPILER=gcc-7 \
-DCMAKE_CXX_COMPILER=g++-7 \
-DENABLE_WEB_CRYPTO=OFF \
-DUSE_GSTREAMER_GL=false \
%endif
%if 0%{?suse_version} <= 1500
-DUSE_WOFF2=false \
%endif
-DENABLE_MINIBROWSER=ON \
%if %{with python3}
-DPYTHON_EXECUTABLE=%{_bindir}/python3 \
%endif
%if !0%{?is_opensuse}
-DENABLE_PLUGIN_PROCESS_GTK2=OFF \
%endif
%ifarch armv6hl ppc ppc64 ppc64le riscv64 s390 s390x
-DENABLE_JIT=OFF \
%endif
-DUSE_SYSTEM_MALLOC=ON \
-DCMAKE_EXE_LINKER_FLAGS="-Wl,--as-needed -Wl,-z,now -pthread" \
-DCMAKE_MODULE_LINKER_FLAGS="-Wl,--as-needed -Wl,-z,now -pthread" \
-DCMAKE_SHARED_LINKER_FLAGS="-Wl,--as-needed -Wl,-z,now -pthread"
which all looks pretty reasonable to me: certain features that require “newer” dependencies are disabled on the old distros, and NPAPI plugins are not supported in the enterprise distro, and JIT doesn’t work on odd architectures. I would remove the ENABLE_JIT=OFF lines only because WebKit’s build system should be smart enough nowadays to disable it automatically to save you the trouble of thinking about which architectures the JIT works on. And I would also remove the -DUSE_SYSTEM_MALLOC=ON line to ensure users are properly protected.
In other packages, especially big ones that build across multiple platforms, USE_SYSTEM_FOO generally refers to looking for dependency FOO in the system rather than building a bundled version.
So if I were a distro maintainer and I had a look at this list of options, I’d enable USE_SYSTEM_MALLOC as well.
Why not make the option self-documenting and name it something like USE_INSECURE_SYSTEM_MALLOC?
While I was considering this, I realized that another option is to just hide it. It used to be important because bmalloc doesn’t work on many architectures, and distro packagers needed to manually disable it on those architectures. Nowadays that should be handled automatically, so I think it really shouldn’t need to be public anymore. So perhaps it will just disappear!
I don’t think that choice is as clear-cut as you present it.
Turn it around: if you avoid system malloc then you are missing out of its security features.
For other projects, turning off system malloc has been the cause of security bugs. Are you really qualified to tell which one is best?