All gnome/gtk packages now are able to use openssl crypt library. It would be good to replace libgcrypt by openssl crypt or libxcrypt.
Careful, ClearKey EME implementation also depends on libgcrypt. Just in case somebody tries without building it...
What's wrong with libgcrypt? or what's the benefit of using openssl instead?
This RFE is is about reduction of the tooling footprint used whole desktop software. If you will look closet of the software which is using webkitgtk you will find that exact programs will be using at least two inf not somethings three crypto libraries. Each library uses jump table. Each jump table is one of the most often used parts of the memory. Less libraries -> less jump tables created by ld.so -> less memory used -> faster program. # for i in 'libgnutls.so.30()(64bit)' 'libgcrypt.so.20()(64bit)' 'libcrypto.so.1.1()(64bit)' 'libssl.so.1.1()(64bit)' 'libcrypt.so.2()(64bit)';do echo -n "$i "; dnf -q repoquery --whatrequires $i |wc -l; done libgnutls.so.30()(64bit) 216 libgcrypt.so.20()(64bit) 130 libcrypto.so.1.1()(64bit) 971 libssl.so.1.1()(64bit) 533 libcrypt.so.2()(64bit) 258 As you see libngcryot is used even less frequently than libxcrypt, gnutls, libxcrypt. It would be nice to have possibility to build webkitgtk against openssl. For example webkitgtk is used by epiphany: ]# ldd /usr/bin/epiphany | egrep "libgnutls.so.30|libgcrypt.so.20|libcrypto.so.1.1|libssl.so.1.1|libcrypt.so.2" libgcrypt.so.20 => /lib64/libgcrypt.so.20 (0x00007fe5642db000) libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007fe563512000) Anfd other: # ldd /usr/bin/devhelp | egrep "libgnutls.so.30|libgcrypt.so.20|libcrypto.so.1.1|libssl.so.1.1|libcrypt.so.2" libgcrypt.so.20 => /lib64/libgcrypt.so.20 (0x00007fc0872be000) libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007fc08458d000) # ldd /usr/bin/geary | egrep "libgnutls.so.30|libgcrypt.so.20|libcrypto.so.1.1|libssl.so.1.1|libcrypt.so.2" libgcrypt.so.20 => /lib64/libgcrypt.so.20 (0x00007f78fdd73000) libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f78fa5bd000)
(In reply to Tomasz Kłoczko from comment #3) > This RFE is is about reduction of the tooling footprint used whole desktop > software. > If you will look closet of the software which is using webkitgtk you will > find that exact programs will be using at least two inf not somethings three > crypto libraries. > Each library uses jump table. Each jump table is one of the most often used > parts of the memory. > Less libraries -> less jump tables created by ld.so -> less memory used -> > faster program. > > # for i in 'libgnutls.so.30()(64bit)' 'libgcrypt.so.20()(64bit)' > 'libcrypto.so.1.1()(64bit)' 'libssl.so.1.1()(64bit)' > 'libcrypt.so.2()(64bit)';do echo -n "$i "; dnf -q repoquery --whatrequires > $i |wc -l; done > libgnutls.so.30()(64bit) 216 > libgcrypt.so.20()(64bit) 130 > libcrypto.so.1.1()(64bit) 971 > libssl.so.1.1()(64bit) 533 > libcrypt.so.2()(64bit) 258 > > As you see libngcryot is used even less frequently than libxcrypt, gnutls, > libxcrypt. > It would be nice to have possibility to build webkitgtk against openssl. > > For example webkitgtk is used by epiphany: > > ]# ldd /usr/bin/epiphany | egrep > "libgnutls.so.30|libgcrypt.so.20|libcrypto.so.1.1|libssl.so.1.1|libcrypt.so. > 2" > libgcrypt.so.20 => /lib64/libgcrypt.so.20 (0x00007fe5642db000) > libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007fe563512000) > > Anfd other: > > # ldd /usr/bin/devhelp | egrep > "libgnutls.so.30|libgcrypt.so.20|libcrypto.so.1.1|libssl.so.1.1|libcrypt.so. > 2" > libgcrypt.so.20 => /lib64/libgcrypt.so.20 (0x00007fc0872be000) > libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007fc08458d000) > > # ldd /usr/bin/geary | egrep > "libgnutls.so.30|libgcrypt.so.20|libcrypto.so.1.1|libssl.so.1.1|libcrypt.so. > 2" > libgcrypt.so.20 => /lib64/libgcrypt.so.20 (0x00007f78fdd73000) > libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f78fa5bd000) This looks like an issue with the packages in your GNU/Linux distribution. WebKitGTK itself only uses libgcrypt directly, and then GnuTLS indirectly through glib-networking (and GnuTLS itself uses libgcrypt) -- the only way in which “libgcrypt” can end up listed there is if any of the dependencies of WebKitGTK links against it. And that depends on hour your distribution packager has done things, which we cannot control. If you want to know to what libraries an ELF object is linked directly, it is much better to use “readelf -d” and look at the DT_NEEDED entries. For example, this is in Arch Linux, which I personally use and *know* that its packages try to keep as close to official packages as possible: % readelf -d /usr/bin/epiphany | grep -E 'NEEDED.*(crypt|tls|ssl)' % readeld -d /usr/lib/gio/modules/libgiognutls.so | grep -E 'NEEDED.*(crypt|tls|ssl)' 0x0000000000000001 (NEEDED) Shared library: [libgnutls.so.30] % readelf -d /usr/lib/libwebkit2gtk-4.0.so | grep -E 'NEEDED.*(crypt|tls|ssl)' 0x0000000000000001 (NEEDED) Shared library: [libgcrypt.so.20] % As you can see, no “libcrypto” in the output. Also, none of the dependency libraries in the full chain pulls OpenSSL, see: % ldd /usr/bin/epiphany|grep -E '(crypt|tls|ssl)' libgcrypt.so.20 => /usr/lib/libgcrypt.so.20 (0x00007f36da916000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00007f36d8264000) (The same output is produced for “devhelp”, I have not tried Geary because I do not have it installed.) Summary: The reason why you end up with both libraries being picked by the dynamic linker is not WebKitGTK itself because it only links directly to libgcrypt; some other dependency in your system is using OpenSSL.
> This looks like an issue with the packages in your GNU/Linux distribution. Nope. This is not only Fedora issue. In All Debian based distros people are completly not aware possibility to minimise dynamically linked libraries by proper decysions on source code configuration stage in case of thsoe projects which have such options. Only handfull packages have options to choose for example crypto backend library on configure source code stage. Majority of the OSS software is using openssl as TLS librarynad libxcrypto (or libcrypto) as crypto bakend. From that point of view choosing libgsryoto was not the best decision. > $ readelf -d /usr/bin/epiphany | grep -E 'NEEDED.*(crypt|tls|ssl)' That command shows what is actually NEEDED by epiphany DSO not what will be loaded into epiphany process adress space. Because I'm buiding all my spftware with -Wl,--as-needed on my epiphany ois not linked like on your system. $ readelf -d /usr/bin/epiphany | grep -E 'NEEDED.*(crypt|tls|ssl)' $ $ objdump -x /usr/bin/epiphany |grep NEEDED NEEDED libc.so.6 NEEDED libephymain.so NEEDED libephymisc.so NEEDED libgtk-3.so.0 NEEDED libgio-2.0.so.0 NEEDED libgobject-2.0.so.0 NEEDED libglib-2.0.so.0 NEEDED libxml2.so.2 NEEDED libhandy-0.0.so.0 In other words your epiphany binary is overlinked. In case my example those two libraries are loaded only because libraries used by epiphany are using different crypt/tls libraries. That what will actually what will be loaded into epiphany adress space by ld.so in my case. I'm almost sure that in your case it will be much more (as I wrote I'm linking everyuthing with --as-needed) [tkloczko@barrel SPECS]$ ldd /usr/bin/epiphany | wc -l 140 [tkloczko@barrel SPECS]$ ldd /usr/bin/epiphany linux-vdso.so.1 (0x00007ffe77bab000) libc.so.6 => /lib64/libc.so.6 (0x00007f35b60f5000) libephymain.so => /usr/lib64/epiphany/libephymain.so (0x00007f35b6016000) libephymisc.so => /usr/lib64/epiphany/libephymisc.so (0x00007f35b5fcc000) libgtk-3.so.0 => /lib64/libgtk-3.so.0 (0x00007f35b58fc000) libgio-2.0.so.0 => /lib64/libgio-2.0.so.0 (0x00007f35b5739000) libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00007f35b56e1000) libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f35b55b3000) libxml2.so.2 => /lib64/libxml2.so.2 (0x00007f35b5436000) libhandy-0.0.so.0 => /lib64/libhandy-0.0.so.0 (0x00007f35b53ce000) /lib64/ld-linux-x86-64.so.2 (0x00007f35b6516000) libephysync.so => /usr/lib64/epiphany/libephysync.so (0x00007f35b53a0000) libdazzle-1.0.so.0 => /lib64/libdazzle-1.0.so.0 (0x00007f35b52b0000) libgdk-3.so.0 => /lib64/libgdk-3.so.0 (0x00007f35b51d7000) libpango-1.0.so.0 => /lib64/libpango-1.0.so.0 (0x00007f35b5183000) libatk-1.0.so.0 => /lib64/libatk-1.0.so.0 (0x00007f35b515a000) libcairo.so.2 => /lib64/libcairo.so.2 (0x00007f35b503f000) libgdk_pixbuf-2.0.so.0 => /lib64/libgdk_pixbuf-2.0.so.0 (0x00007f35b5014000) libjson-glib-1.0.so.0 => /lib64/libjson-glib-1.0.so.0 (0x00007f35b4fe7000) libsoup-2.4.so.1 => /lib64/libsoup-2.4.so.1 (0x00007f35b4f44000) libm.so.6 => /lib64/libm.so.6 (0x00007f35b4dfc000) libwebkit2gtk-4.0.so.37 => /lib64/libwebkit2gtk-4.0.so.37 (0x00007f35b1b3d000) libjavascriptcoregtk-4.0.so.18 => /lib64/libjavascriptcoregtk-4.0.so.18 (0x00007f35b040a000) libgcr-ui-3.so.1 => /lib64/libgcr-ui-3.so.1 (0x00007f35b03a6000) libgcr-base-3.so.1 => /lib64/libgcr-base-3.so.1 (0x00007f35b0318000) libsqlite3.so.0 => /lib64/libsqlite3.so.0 (0x00007f35b01e4000) libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x00007f35b01dc000) libpangocairo-1.0.so.0 => /lib64/libpangocairo-1.0.so.0 (0x00007f35b01ca000) libXi.so.6 => /lib64/libXi.so.6 (0x00007f35b01b8000) libXfixes.so.3 => /lib64/libXfixes.so.3 (0x00007f35b01af000) libcairo-gobject.so.2 => /lib64/libcairo-gobject.so.2 (0x00007f35b01a3000) libatk-bridge-2.0.so.0 => /lib64/libatk-bridge-2.0.so.0 (0x00007f35b016a000) libwayland-client.so.0 => /lib64/libwayland-client.so.0 (0x00007f35b0158000) libepoxy.so.0 => /lib64/libepoxy.so.0 (0x00007f35b0023000) libX11.so.6 => /lib64/libX11.so.6 (0x00007f35afee0000) libfribidi.so.0 => /lib64/libfribidi.so.0 (0x00007f35afec1000) libpangoft2-1.0.so.0 => /lib64/libpangoft2-1.0.so.0 (0x00007f35afea7000) libharfbuzz.so.0 => /lib64/libharfbuzz.so.0 (0x00007f35afdd7000) libfontconfig.so.1 => /lib64/libfontconfig.so.1 (0x00007f35afd98000) libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007f35afcd6000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f35afcb4000) libz.so.1 => /lib64/libz.so.1 (0x00007f35afc9a000) libmount.so.1 => /lib64/libmount.so.1 (0x00007f35afc61000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f35afc34000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f35afc18000) libffi.so.6 => /lib64/libffi.so.6 (0x00007f35afc0d000) libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f35afb94000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f35afb8d000) liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f35afb62000) libsecret-1.so.0 => /lib64/libsecret-1.so.0 (0x00007f35afb15000) libgmp.so.10 => /lib64/libgmp.so.10 (0x00007f35afa71000) libhogweed.so.6 => /lib64/libhogweed.so.6 (0x00007f35afa27000) libnettle.so.8 => /lib64/libnettle.so.8 (0x00007f35af9e4000) librt.so.1 => /lib64/librt.so.1 (0x00007f35af9d9000) libXinerama.so.1 => /lib64/libXinerama.so.1 (0x00007f35af9d4000) libXrandr.so.2 => /lib64/libXrandr.so.2 (0x00007f35af9c5000) libXcursor.so.1 => /lib64/libXcursor.so.1 (0x00007f35af9b8000) libXcomposite.so.1 => /lib64/libXcomposite.so.1 (0x00007f35af9b3000) libXdamage.so.1 => /lib64/libXdamage.so.1 (0x00007f35af9ae000) libxkbcommon.so.0 => /lib64/libxkbcommon.so.0 (0x00007f35af972000) libwayland-cursor.so.0 => /lib64/libwayland-cursor.so.0 (0x00007f35af968000) libwayland-egl.so.1 => /lib64/libwayland-egl.so.1 (0x00007f35af961000) libXext.so.6 => /lib64/libXext.so.6 (0x00007f35af94c000) libthai.so.0 => /lib64/libthai.so.0 (0x00007f35af941000) libpixman-1.so.0 => /lib64/libpixman-1.so.0 (0x00007f35af896000) libpng16.so.16 => /lib64/libpng16.so.16 (0x00007f35af85c000) libxcb-shm.so.0 => /lib64/libxcb-shm.so.0 (0x00007f35af855000) libxcb.so.1 => /lib64/libxcb.so.1 (0x00007f35af82b000) libxcb-render.so.0 => /lib64/libxcb-render.so.0 (0x00007f35af81c000) libXrender.so.1 => /lib64/libXrender.so.1 (0x00007f35af80f000) libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f35af7bb000) libpsl.so.5 => /lib64/libpsl.so.5 (0x00007f35af7b4000) libbrotlidec.so.1 => /lib64/libbrotlidec.so.1 (0x00007f35af7a4000) libwpe-1.0.so.1 => /lib64/libwpe-1.0.so.1 (0x00007f35af799000) libWPEBackend-fdo-1.0.so.1 => /lib64/libWPEBackend-fdo-1.0.so.1 (0x00007f35af787000) libGL.so.1 => /lib64/libGL.so.1 (0x00007f35af700000) libEGL.so.1 => /lib64/libEGL.so.1 (0x00007f35af6ee000) libnotify.so.4 => /lib64/libnotify.so.4 (0x00007f35af6e4000) libicui18n.so.67 => /lib64/libicui18n.so.67 (0x00007f35af416000) libicuuc.so.67 => /lib64/libicuuc.so.67 (0x00007f35af23e000) libsystemd.so.0 => /lib64/libsystemd.so.0 (0x00007f35af198000) libxslt.so.1 => /lib64/libxslt.so.1 (0x00007f35af15a000) libwoff2dec.so.1.0.2 => /lib64/libwoff2dec.so.1.0.2 (0x00007f35af14f000) libharfbuzz-icu.so.0 => /lib64/libharfbuzz-icu.so.0 (0x00007f35af14a000) libgcrypt.so.20 => /lib64/libgcrypt.so.20 (0x00007f35af023000) libgstapp-1.0.so.0 => /lib64/libgstapp-1.0.so.0 (0x00007f35af012000) libgstbase-1.0.so.0 => /lib64/libgstbase-1.0.so.0 (0x00007f35aefce000) libgstreamer-1.0.so.0 => /lib64/libgstreamer-1.0.so.0 (0x00007f35aeeff000) libgstpbutils-1.0.so.0 => /lib64/libgstpbutils-1.0.so.0 (0x00007f35aeec5000) libgstaudio-1.0.so.0 => /lib64/libgstaudio-1.0.so.0 (0x00007f35aee66000) libgsttag-1.0.so.0 => /lib64/libgsttag-1.0.so.0 (0x00007f35aee33000) libgstvideo-1.0.so.0 => /lib64/libgstvideo-1.0.so.0 (0x00007f35aed95000) libgstgl-1.0.so.0 => /lib64/libgstgl-1.0.so.0 (0x00007f35aed2e000) libgstfft-1.0.so.0 => /lib64/libgstfft-1.0.so.0 (0x00007f35aed22000) libjpeg.so.62 => /lib64/libjpeg.so.62 (0x00007f35aecaf000) libopenjp2.so.7 => /lib64/libopenjp2.so.7 (0x00007f35aec5c000) libwebpdemux.so.2 => /lib64/libwebpdemux.so.2 (0x00007f35aec54000) libwebp.so.7 => /lib64/libwebp.so.7 (0x00007f35aebe8000) libenchant-2.so.2 => /lib64/libenchant-2.so.2 (0x00007f35aebda000) libseccomp.so.2 => /lib64/libseccomp.so.2 (0x00007f35aebbd000) libtasn1.so.6 => /lib64/libtasn1.so.6 (0x00007f35aeba6000) libhyphen.so.0 => /lib64/libhyphen.so.0 (0x00007f35aeb9f000) libwayland-server.so.0 => /lib64/libwayland-server.so.0 (0x00007f35aeb88000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f35ae9a0000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f35ae985000) libgck-1.so.0 => /lib64/libgck-1.so.0 (0x00007f35ae952000) libp11-kit.so.0 => /lib64/libp11-kit.so.0 (0x00007f35ae820000) libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x00007f35ae7c4000) libatspi.so.0 => /lib64/libatspi.so.0 (0x00007f35ae78b000) libgraphite2.so.3 => /lib64/libgraphite2.so.3 (0x00007f35ae76a000) libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f35ae756000) libblkid.so.1 => /lib64/libblkid.so.1 (0x00007f35ae729000) libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007f35ae691000) libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007f35ae66c000) libdatrie.so.1 => /lib64/libdatrie.so.1 (0x00007f35ae663000) libXau.so.6 => /lib64/libXau.so.6 (0x00007f35ae65e000) libXdmcp.so.6 => /lib64/libXdmcp.so.6 (0x00007f35ae656000) libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f35ae57c000) libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f35ae564000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f35ae55d000) libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f35ae54c000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f35ae545000) libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f35ae25a000) libidn2.so.0 => /lib64/libidn2.so.0 (0x00007f35ae237000) libunistring.so.2 => /lib64/libunistring.so.2 (0x00007f35ae0b4000) libbrotlicommon.so.1 => /lib64/libbrotlicommon.so.1 (0x00007f35ae091000) libGLX.so.0 => /lib64/libGLX.so.0 (0x00007f35ae05f000) libGLdispatch.so.0 => /lib64/libGLdispatch.so.0 (0x00007f35adfa8000) libicudata.so.67 => /lib64/libicudata.so.67 (0x00007f35ac48f000) libzstd.so.1 => /lib64/libzstd.so.1 (0x00007f35ac3e1000) liblz4.so.1 => /lib64/liblz4.so.1 (0x00007f35ac3be000) libwoff2common.so.1.0.2 => /lib64/libwoff2common.so.1.0.2 (0x00007f35ac3b9000) liborc-0.4.so.0 => /lib64/liborc-0.4.so.0 (0x00007f35ac335000) libgstallocators-1.0.so.0 => /lib64/libgstallocators-1.0.so.0 (0x00007f35ac32d000) libX11-xcb.so.1 => /lib64/libX11-xcb.so.1 (0x00007f35ac328000) libgudev-1.0.so.0 => /lib64/libgudev-1.0.so.0 (0x00007f35ac31c000) libdrm.so.2 => /lib64/libdrm.so.2 (0x00007f35ac308000) libgbm.so.1 => /lib64/libgbm.so.1 (0x00007f35ac2f6000) libudev.so.1 => /lib64/libudev.so.1 (0x00007f35ac2cc000) libexpat.so.1 => /lib64/libexpat.so.1 (0x00007f35ac29d000) As you can see issue with crypto/tls libaries it is not only issue. it is another simillar issue with xml parsers [tkloczko@barrel SPECS]$ ldd /usr/bin/epiphany |egrep "xml|expat" libxml2.so.2 => /lib64/libxml2.so.2 (0x00007fcc79b99000) libexpat.so.1 => /lib64/libexpat.so.1 (0x00007fcc70a00000) And I'm working on reduce above as well .. :)
(In reply to Tomasz Kłoczko from comment #3) > This RFE is is about reduction of the tooling footprint used whole desktop > software. > If you will look closet of the software which is using webkitgtk you will > find that exact programs will be using at least two inf not somethings three > crypto libraries. > Each library uses jump table. Each jump table is one of the most often used > parts of the memory. > Less libraries -> less jump tables created by ld.so -> less memory used -> > faster program. > Do you have example measurements of improved memory consumption and performance due to such changes on some other program/library?
I actually agree with Tomasz. Linux has too many crypto libraries in the base platform, and maintaining them all requires significant effort and expense, so there is interest in removing use of libgcrypt wherever possible. (In reply to Carlos Garcia Campos from comment #2) > What's wrong with libgcrypt? or what's the benefit of using openssl instead? OK I know this is going to be really vague, as I don't know much about libgcrypt, but: "problematic architecture and maintainability." I have heard many less-kind things said about libgcrypt. Notably, its strange initialization routines cause it to be unsafe to use from libraries, so for that reason alone it's dramatically less useful than other system crypto libraries. (That's not directly a problem for WebKit, because we only use it in the web process executable, not the library component of WebKit.) As far as GNOME is concerned, we only have to deal with WebKitGTK and libsecret. (I don't know what the goal is for other stuff like gnupg.) Anyway, at first I was concerned about this because we need Zan's libgcrypt backend for WebCrypto, but then I discovered that Sony has already developed an alternative OpenSSL backend for WebCrypto that we could use instead. I was planning to propose switching WebKitGTK 2.32 to use the OpenSSL backend by default if OpenSSL 3 is detected, while falling back to libgcrypt for older versions of OpenSSL. (We're planning to ship OpenSSL 3 in Fedora 34. This OpenSSL license change is a really big deal. Previously, we could not safely link WebKit directly to OpenSSL, but now with this license change, I wouldn't be surprised if OpenSSL begins slowly replacing other crypto libraries over the next decade.)
(BTW, I still think libgcrypt was a good choice to use for WebCrypto at the time the feature was developed. We had to avoid LGPLv3, GPL, and OpenSSL licenses. With those restrictions, the choice made sense. We couldn't have predicted back then that it would eventually become possible to consider OpenSSL.)
https://en.wikipedia.org/wiki/Apache_License#Compatibility(In reply to Tomasz Kłoczko from comment #5) > > This looks like an issue with the packages in your GNU/Linux distribution. > > Nope. This is not only Fedora issue. In All Debian based distros people are > completly not aware possibility to minimise dynamically linked libraries by > proper decysions on source code configuration stage in case of thsoe > projects which have such options. > > Only handfull packages have options to choose for example crypto backend > library on configure source code stage. > AFAIK Debian based distributions choose to use libgcrypt over OpenSSL whenever possible to avoid the license issues with the OpenSSL license and the GPL (read at bottom of this comment about the new license of OpenSSL). There is even a lintian tag that warns when you try to link a GPL package with OpenSSL: https://lintian.debian.org/tags/possible-gpl-code-linked-with-openssl.html In the case of Fedora based distros this is not a problem because Fedora decided to declare OpenSSL part of the core operating system, therefore the linking exception of the GPL license applies <https://www.gnu.org/licenses/gpl-faq.en.html#SystemLibraryException> But Debian distros decided against this. (In reply to Michael Catanzaro from comment #8) > (BTW, I still think libgcrypt was a good choice to use for WebCrypto at the > time the feature was developed. We had to avoid LGPLv3, GPL, and OpenSSL > licenses. With those restrictions, the choice made sense. We couldn't have > predicted back then that it would eventually become possible to consider > OpenSSL.) OpenSSL new license is Apache v2, which to the best of my knowledge is also not compatible with the GPLv2 license (GPLv2-only). See: https://www.apache.org/licenses/GPL-compatibility.html https://en.wikipedia.org/wiki/Apache_License#Compatibility So my understanding is that if we switch WebKit to use OpenSSL then WebKit itself will be incompatible (license-wise) with GPLv2-only applications (or libraries). I'm missing something here?
I agree we need to avoid OpenSSL license, because only Red Hat allows combining OpenSSL license with GPLv2. (In reply to Carlos Alberto Lopez Perez from comment #9) > So my understanding is that if we switch WebKit to use OpenSSL then WebKit > itself will be incompatible (license-wise) with GPLv2-only applications (or > libraries). > > I'm missing something here? That's all correct. I think it doesn't matter, though. (a) I don't know of any real GPLv2-only application that uses WebKit. Actual apps are GPLv2-or-later, which is OK since it automatically upgrades to GPLv3-or-later. (b) Even if such an application does exist, I'm unsympathetic, since GPLv2-only license is strongly discouraged by GNU/FSF. Applications using it should know they are setting themselves up for pain and license trouble if they aren't very careful about what they link to. So I think, in practice, we should be fine as long as we are careful to never link to older OpenSSL versions. (Sadly, it seems BoringSSL will stick with the OpenSSL license, so this only applies to upstream OpenSSL.) One more thing: glib-networking *might* (or might not) eventually switch its default backend to OpenSSL (if OpenSSL v3 is available) as well.
(In reply to Zan Dobersek from comment #6) > (In reply to Tomasz Kłoczko from comment #3) > > This RFE is is about reduction of the tooling footprint used whole desktop > > software. > > If you will look closet of the software which is using webkitgtk you will > > find that exact programs will be using at least two inf not somethings three > > crypto libraries. > > Each library uses jump table. Each jump table is one of the most often used > > parts of the memory. > > Less libraries -> less jump tables created by ld.so -> less memory used -> > > faster program. > > > > Do you have example measurements of improved memory consumption and > performance due to such changes on some other program/library? I'm also interested in seeing any memory measurement data or performance benchmark.
(In reply to Michael Catanzaro from comment #7) [...] > Anyway, at first I was concerned about this because we need Zan's libgcrypt > backend for WebCrypto, but then I discovered that Sony has already developed > an alternative OpenSSL backend for WebCrypto that we could use instead. I > was planning to propose switching WebKitGTK 2.32 to use the OpenSSL backend > by default if OpenSSL 3 is detected, while falling back to libgcrypt for > older versions of OpenSSL. > > (We're planning to ship OpenSSL 3 in Fedora 34. This OpenSSL license change > is a really big deal. Previously, we could not safely link WebKit directly > to OpenSSL, but now with this license change, I wouldn't be surprised if > OpenSSL begins slowly replacing other crypto libraries over the next decade.) FWIW, the FDO SDK now ships OpenSSL 3, since the 22.08 release. I dunno what is the status in distros, but would this proposal of depending on OpenSSL 3 now be actually doable?
The GstWebRTC backend depends on OpenSSL already BTW. So we do have a duplicate dependency now. Also about EME ClearKey, we no longer directly depend on libgcrypt for that. There is a sparkle-cdm plugin handling clearkey, which does use libgcrypt though...
(In reply to Philippe Normand from comment #12) > FWIW, the FDO SDK now ships OpenSSL 3, since the 22.08 release. I dunno what > is the status in distros, but would this proposal of depending on OpenSSL 3 > now be actually doable? I think is doable as long as you take into account out minimum dependencies policy: https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy - If using OpenSSL3 is optional (one can fall-back to libgcrypt with a CMake option) then I see no issue adding it, as old distros can opt to build with libgcrypt like they are doing now. - But if using OpenSSL3 will be mandatory then we need to wait until the oldest of the distros that we support ships OpenSSL-3
Yeah we can fallback to libgcrypt if openssl3 isn't found indeed. And about GstWebRTC, i'm afraid we'd need to disable it if openssl3 isn't found...
I agree with Carlos Lopez. Disabling WebRTC if OpenSSL 3 is not available is perfectly fine. New features require new dependencies: that's normal and not a regression for older environments.