Package Details: librewolf-bin 1:140.0.2_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: 507
Popularity: 28.73
First Submitted: 2019-06-16 13:12 (UTC)
Last Updated: 2025-06-28 22:34 (UTC)

Required by (37)

Sources (7)

Pinned Comments

lsf commented on 2021-11-10 12:14 (UTC) (edited on 2023-04-17 07:18 (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 :)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 .. 22 Next › Last »

karolyi commented on 2025-03-19 15:58 (UTC)

@spsf64, it works on my machine™

zlima12 commented on 2025-03-15 18:37 (UTC) (edited on 2025-03-15 18:38 (UTC) by zlima12)

@marbens yes, that would not have been that big of a deal considering the upstream release cadence. epoch bumps are only supposed to be used for major versioning breakage (e.g. 5.7.2 gets reset to 1.0.0). Really, I think that it should get reset to zero/undefined in the case of this package, but as mentioned before that would require manual intervention from users that have updated to epoch 1.

marbens commented on 2025-03-15 07:54 (UTC) (edited on 2025-03-15 07:58 (UTC) by marbens)

@zlima12 How else would we have solved the problem? Skip 136.0-2?

zlima12 commented on 2025-03-15 00:15 (UTC) (edited on 2025-03-15 00:17 (UTC) by zlima12)

I really don't think that an epoch bump was warranted here. There was no profound change in the upstream versioning system, and the versioning problem would have only lasted until 136.1 or 137 was released. Now, there is no way to undo the epoch change without manual intervention from the users that have already updated.

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.

« First ‹ Previous 1 2 3 4 5 6 7 .. 22 Next › Last »