| 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: | 23.77 |
| First Submitted: | 2019-06-16 13:12 (UTC) |
| Last Updated: | 2026-05-13 07:44 (UTC) |
Manjaro site shows
As stated earlier I, ron2138, use pacman 6.0.2-9 and pacman-contrib 1.10.4-3. Current versions in arch stable are 6.1.0-3, and 1.10.5-1, respectively. For arch stable, pacman 6.1.0-3 is 6.0.2-9 successor. While pacman-contrib had 1.10.4-4 in between 1.10.4-3 and 1.10.5-1.
FWIW I have this issue with the failing validity check on Manjaro stable install with pamac and yay. I could check later with my EndeavourOS install.
With the suggested SKIP checksum, I get:
$ makepkg --verifysource --force
==> Making package: librewolf-bin 125.0.2-1 (Fri 26 Apr 2024 12:23:23 AM UTC)
==> Retrieving sources...
-> Updating source git repo...
-> Found default192x192.png
-> Found librewolf.desktop
-> Found librewolf-125.0.2-1-linux-x86_64-package.tar.bz2
-> Found librewolf-125.0.2-1-linux-x86_64-package.tar.bz2.sig
==> Validating source files with sha256sums...
source ... Skipped
default192x192.png ... Passed
librewolf.desktop ... Passed
==> Validating source_x86_64 files with sha256sums...
librewolf-125.0.2-1-linux-x86_64-package.tar.bz2 ... Passed
librewolf-125.0.2-1-linux-x86_64-package.tar.bz2.sig ... Skipped
==> Verifying source file signatures with gpg...
librewolf-125.0.2-1-linux-x86_64-package.tar.bz2 ... Passed
(The reason for --force is because I already built the package. makepkg is not willing to run without it.)
I think it does validate the source after the SKIP at sha256sums is evaluated.
==> Validating source_x86_64 files with sha256sums...
librewolf-125.0.2-1-linux-x86_64-package.tar.bz2 ... Passed
librewolf-125.0.2-1-linux-x86_64-package.tar.bz2.sig ... Skipped
I haven't looked what was in the PKGBUILD in previous versions. The current problem could be related to the source, source_aarch64, source_x86_64, sha256sums, sha256sums_x86_64, and sha256sums_aarch64 arrays. And the way makepkg verifies the sums. I agree this is what is being called hands waiving rather then a concise explanation. But, since there is a source_x86_64 verification, I have not tried harder.
I have this issue, and I am not on Manjaro. As lsf suggested at 2024-04-25 19:51 (UTC), I deliberately keep pacman/pacman-contrib versions behind. I have other issues with the up to date versions, which is why I have downgraded. Waiting to see if those issues get resolved in their next versions. On the other hand, even though I am hardly building AUR packages, this is the 1st time I run into such an issue. Could it be the very few other AUR packages I built lately have issues I am not aware of?
*she.
more to the point though: while it still builds/verifies cleanly for me, it doesn't make sense to have a checksum on a folder / git checkout. I didn't manually add it, I usually just trust updpkgsums to do its job. For some reason though, it insists on adding a checksum… for the git checkout's folder this time.
So skipping the verification for that checkout would be a reasonable approach for now. I'll still try to find out why it's in there this time around at all, and then see about updating the PKGBUILD ^^
(sorry for the trouble this seems to have caused!)
/edit: just in case: are those folks who have that issue on manjaro? maybe it's just part of the newer(ish) pacman/pacman-contrib versions, seems like manjaro is a bit behind there still?
I get the same error ron2138 so guess it's the same for all of us but (If I understand it correctly) skipping the verification is not a fix, it's a bypass at most and not a particularly convincing one, cause why would I wanna have potential errors or even malicious code in a browser source? Especially since he seems to have removed the SKIP command from a previous version, thus probably wanting to improve it. It seems to me the sha256 used in the pkgbuild is just wrong as the one I get from the source.tar.gz.sha256sum on Codeberg¹ is not found in it, but ² instead.
¹ aafe820d94a535728bc4d247a120f3ceed2d6df49b044c60b231009ab06a1f27
² 84513d4d5387f09231bb2f426596f24897babfc77c8e502001650531e375f9f9
Now is that an argument against unsigned sha256sums or just a human error?
I get the following after previously downloading librewolf-125.0.2-1-linux-x86_64-package.tar.bz2*. Could be the same issue as Exod1us reported at 2024-04-24 18:22 (UTC).
$ ls --size librewolf-125*
94648 librewolf-125.0.2-1-linux-x86_64-package.tar.bz2
4 librewolf-125.0.2-1-linux-x86_64-package.tar.bz2.sig
$ makepkg --verifysource
==> Making package: librewolf-bin 125.0.2-1 (Thu 25 Apr 2024 03:28:11 PM UTC)
==> Retrieving sources...
-> Updating source git repo...
-> Found default192x192.png
-> Found librewolf.desktop
-> Found librewolf-125.0.2-1-linux-x86_64-package.tar.bz2
-> Found librewolf-125.0.2-1-linux-x86_64-package.tar.bz2.sig
==> Validating source files with sha256sums...
source ... NOT FOUND
default192x192.png ... Passed
librewolf.desktop ... Passed
==> ERROR: One or more files did not pass the validity check!
That particular ERROR solved by issuing
$ sed -i "/sha256sums=(/s:'.*:'SKIP':" PKGBUILD
before makepkg --verifysource. I hope it will also solves Exod1us issue reported at 2024-04-24 18:22 (UTC), if he will issue that sed command right after he obtained the PKGBUILD file. But have not verified this last statement.
Whith the last update he can't get the source. Error when update
There was new release https://codeberg.org/librewolf/source/releases/tag/125.0.1-1
ignxcy: Same question
Why is it marked out of date??
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.