Something is wrong with the performance of this binary on my Ryzen 9 5900X. When I test performance with https://browserbench.org/Speedometer3.0/ I get a score of only 11,9. Firefox with the same version 128.0.3 reaches a score of 13,7, which is 15 % better. Since both are using the same source code I would assume librewolf-bin is using different compiler options. When I compile librewolf by myself with
CFLAGS="-march=x86-64-v3 -O2 -pipe -fno-plt -fexceptions \
-Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security \
-fstack-clash-protection -fcf-protection"
I get a score of 15,9, which is excellent. Only exceeded by Chromium with 17,9. So something seems to be odd with the compiler options used to build librewolf-bin.
Pinned Comments
lsf commented on 2021-11-10 12:14 (UTC) (edited on 2026-05-07 09:38 (UTC) by lsf)
https://wiki.archlinux.org/title/Arch_User_Repository#Acquire_a_PGP_public_key_if_needed
gpg --keyserver hkp://keyserver.ubuntu.com --search-keys 031F7104E932F7BD7416E7F6D2845E1305D6E801/edit: starting with 112.0-1, the binaries are signed with the maintainers shared key, so
gpg --keyserver hkp://keyserver.ubuntu.com --search-keys 662E3CDD6FE329002D0CA5BB40339DD82B12EF16should do the trick instead. I've also signed the key with the previously used key, so you have at least some guarantee that it's not a malicious attack :)/edit: (2026-05-07): The upstream signing sub-key was rotated, and the
.tar.xztarballs will now be signed with a new subkey. The main key id (0x662E3CDD6FE329002D0CA5BB40339DD82B12EF16) remains unchanged though, so should you get an error during signature verification about a missing (sub)key, all that's required would be to refresh the key(s) viagpg --refresh-keys 662E3CDD6FE329002D0CA5BB40339DD82B12EF16.