[Webkit-unassigned] [Bug 216201] [GTK]: RFE: remove using libgcryot

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=216201

Adrian Perez <aperez at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aperez at igalia.com

--- Comment #4 from Adrian Perez <aperez at igalia.com> ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200909/137d7357/attachment.htm>