Package Details: librewolf-bin 1:152.0.6_1-1

Git Clone URL: https://aur.archlinux.org/librewolf-bin.git (read-only, click to copy)
Package Base: librewolf-bin
Description: Community-maintained fork of Firefox, focused on privacy, security and freedom.
Upstream URL: https://librewolf.net/
Keywords: browser web
Licenses: MPL-2.0
Conflicts: librewolf
Provides: librewolf
Submitter: lsf
Maintainer: lsf
Last Packager: lsf
Votes: 644
Popularity: 19.43
First Submitted: 2019-06-16 13:12 (UTC)
Last Updated: 2026-07-15 08:05 (UTC)

Required by (40)

Sources (7)

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 662E3CDD6FE329002D0CA5BB40339DD82B12EF16 should 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.xz tarballs 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) via gpg --refresh-keys 662E3CDD6FE329002D0CA5BB40339DD82B12EF16.

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 11 12 .. 29 Next › Last »

sipak commented on 2025-11-03 18:47 (UTC)

Oh, I see. Indeed, the 8A74EAAF89C17944 is a subkey buried under https://rpm.librewolf.net/pubkey.gpg That's why I did not se any reference to it. Thank you for the verification. I too confirm key 8A74EAAF89C17944 is valid.

ZLima12 commented on 2025-11-03 08:51 (UTC)

Yes, 8A74EAAF89C17944 is a subkey of 662E3CDD6FE329002D0CA5BB40339DD82B12EF16 which does indeed appear to be the authentic key: https://codeberg.org/librewolf/issues/issues/2337

lsf commented on 2025-11-03 08:47 (UTC)

@sipak: 8A74EAAF89C17944 is the signing subkey of the key (662E3CDD6FE329002D0CA5BB40339DD82B12EF16) that's in the PKGBUILD. The output showing unknown public key 8A74EAAF89C17944 if it's missing is a bit unhelpful/confusing though, understandably.

If you have the key imported, you can check it via gpg --keyid-format long --list-keys 8A74EAAF89C17944, for example, or by looking at the details of the key at https://keyserver.ubuntu.com/pks/lookup?search=8A74EAAF89C17944&fingerprint=on&op=index .

sipak commented on 2025-11-03 08:00 (UTC)

I am not sure that 8A74EAAF89C17944 is a valid key. Anybody can upload keys to ubuntu key server and claim to be somebody else.

I cannot find any reference to this key in any of the official librewolf sites. Example: https://codeberg.org/librewolf/arch

lsf commented on 2025-10-07 07:15 (UTC)

I very much appreciate you coming back and apologizing. (fwiw: my reply, then, was also not as "neutrally phrased" as it maybe should've been) It's understandable, I guess, especially with an issue like this one that I should have spotted myself (usually, I watch/follow Arch upstreams's Firefox PKGBUILD changes; but, well: not always, as should now be obvious).

So: it was indeed useful; thanks :)

lone-cloud commented on 2025-10-06 23:07 (UTC)

Sorry for the heated words. I spent an hour testing and fixing the issue this morning and was not happy. Hope at least the fix was useful.

lsf commented on 2025-10-06 22:40 (UTC)

Maybe, my dearest @lone-cloud, the issue might be somewhat related to the fact that we're currently more or less one-and-a-half people at best maintaining pretty much the whole thing.

That's very much not optimal, true.

More importantly though: your approach to handling a packaging issue you've spotted is pretty much not helping, and would be disheartening, if it weren't for me being stubborn, I guess. (Also, I wouldn't want to leave the only other remaining core maintainer completely alone with the project, so "stepping down" is not an option.)

Way more words than I should've spent on this, so: on with more productive things.

Thanks for bringing this issue to my attention. Huge thanks to @DKMellow on Codeberg for the PR. I'll take care of merging it and updating the PKGBUILDs tomorrow, as soon as I've gotten a few hours of sleep.

spsf64 commented on 2025-10-06 21:53 (UTC) (edited on 2025-10-06 21:54 (UTC) by spsf64)

@lone-cloud instead of complaining and cursing at the maintainer, you could have, politely, asked him/her to become a co-maintainer or suggest a patch/fix...

dpirate commented on 2025-10-03 15:32 (UTC)

In the .desktop file shipped in this package, there's "StartupWMClass=LibreWolf". This is wrong. It should be "StartupWMClass=librewolf". Or else Plank won't recognise LibreWolf's desktop file and you can't keep in dock.

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 11 12 .. 29 Next › Last »