Package Details: librewolf-bin 1:150.0.3_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: 626
Popularity: 24.26
First Submitted: 2019-06-16 13:12 (UTC)
Last Updated: 2026-05-13 07:44 (UTC)

Required by (39)

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 .. 4 5 6 7 8 9 10 11 12 13 14 .. 29 Next › Last »

libresx commented on 2025-03-12 22:19 (UTC) (edited on 2025-03-12 22:20 (UTC) by libresx)

Cannot be installed because of librewolf-136.0-2-linux-x86_64-package.tar.xz.sig unverified RSA key. Signature has been made 06 March 2025.

BarkleyIII commented on 2025-03-11 08:54 (UTC)

@Powerless That should be fine, as long as the fingerprint of librewolf.asc matches the fingerprint from the librewolf FAQ: https://librewolf.net/docs/faq/#is-importing-gpg-key-0x2b12ef16-ok

Powerless commented on 2025-03-11 00:16 (UTC)

What the hack is going on with this GPG thing? Is this safe to do what @daniel-kuehn said?

"https://gpg.librewolf.net

Then import it with:

gpg --import librewolf.asc "

marbens commented on 2025-03-07 05:40 (UTC) (edited on 2025-03-07 05:41 (UTC) by marbens)

It shows Linux as my user agent (Mozilla/5.0 (X11; Linux x86_64; rv:136.0) Gecko/20100101 Firefox/136.0), even with ResistFingerprinting enabled. Is this intentional, or a regression? It used to not.

marbens commented on 2025-03-06 02:51 (UTC)

I've opened another PR attempting to fix the versioning problems, that are caused by variable-place versioning.

marbens commented on 2025-03-05 14:31 (UTC) (edited on 2025-03-05 14:42 (UTC) by marbens)

If 136.0-2 releases right after 136.0-1, the 4-point solution will require an epoch bump (to 1 at the moment).

But if 136.0.1-1 or 137.0-1 releases right after 136.0-1, we can do the 4-point transition at the same time as the upstream firefox update and avoid using epoch.

BTW you can use an underscore instead of a period for the final version number point (librewolf patch number?), in the 4-point versioning, if you prefer how it looks.

I wasn't thinking about the versioning having a variable amount of points when I made that patch.

lsf commented on 2025-03-05 14:02 (UTC)

Hm. Crap.

…maybe I should've just left it as is (it's always still a possibility to use the pkgrel and go with something like 136.0-1.1, for example, if AUR/PKGBUILD only changes/rebuilds were required).

Going with 4 places always doesn't seem to "sit right" with me as well on the first glance, but I'll need to think about this for a bit.

Thanks a lot for noticing (and for making me aware of this, including a potential solution even)! :)

petris commented on 2025-03-05 13:53 (UTC)

I noticed the version number change to use an underscore, I assume in an effort to decouple the pkgrel from the librewolf version number. Unfortunately it appears this is going to cause some problems.

Lets assume that 136.0-2 is released, and then 136.0.1-1 after that, as librewolf regularly uses the third position as well. A quick test with vercmp shows that 136.0_2 is considered "newer" than 136.0.1_1. My assumption is that it just sees the _ as a separator just like ., and therefore what it's really seeing is 136.0.2 vs 136.0.1.1, which would be correct.

You could probably fix this by making the pkgver always use 4 places (3 for the version and 1 for the pkgrel), using the following as an example:

pkgver="136.0.0.1"
_releaserel="${pkgver##*.}" # Effectively gives you the last segment, resulting in "1".
_releaseverfull="${pkgver%.*}" # Effectively removes the last segment, resulting in "136.0.0"
_releasever="${_releaseverfull/.0}" # Removes ".0" from the end. For "136.0.0" this will result in "136.0" but for "136.0.1" won't do anything.

Then use the _releasever and _releaserel parameters for constructing the actual librewolf version.

daniel-kuehn commented on 2025-03-01 12:09 (UTC)

@AstroBarker Builds/installs fine with yay for me, it's an issue on your end and this package shouldn't be flagged out of date because of that.

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