[aur-general] The AUR package "svp" is suspicious
santiago at archlinux.org
Sat Jun 29 22:59:46 UTC 2019
On Sat, Jun 29, 2019 at 09:18:37PM +0000, Hirela via aur-general wrote:
> TL;DR: The AUR package "svp" (https://aur.archlinux.org/packages/svp/) might be injecting suspicious binary patches.
> Here are the relevant lines from the PKGBUILD version 22.214.171.124:
> # I am rehosting the binaries
> # taken from
> # http://www.svp-team.com/files/svp4-linux-64.tbz2
> # at https://gist.github.com/phiresky/1e2cbd30bed4e5978771af232d11afd1
> # so they are correctly versioned and old versions still exist
> First of all, I do not agree with him rehosting binary software and would much prefer this PKGBUILD to just download the latest version of svp4-linux-64.tbz2 straight from the official source. Since this is proprietary freeware, the maintainer might not have a license to redistribute binaries, and even if he did, the advantage of "correctly versioned" does not match up to the disadvantage of having to trust the maintainer to not tamper with his rehosted versions. Loose versions are acceptable for all the *-git packages, so it should be acceptable for SVP.
> I decided to get the binaries from the official source to verify whether his rehosted packages weren't tampered with. The package version of the PKGBUILD (126.96.36.199) matches up with the latest version of SVP according to the official website (https://www.svp-team.com/wiki/Main_Page). I tried downloading the SVP binary from the official source and compare the hashes:
> $ curl https://www.svp-team.com/files/svp4-linux-64.tbz2 > svp4-linux-64.tbz2
> $ sha256sum svp4-linux-64.tbz2
> 070411ab60d429e03632fa80bb3ded7d5b2c60c2f5b85dff136f65eb83da3bdb svp4-linux-64.tbz2
> This hash does not match up with the hash claimed by the PKGBUILD for his rehosted version, which suggests that the rehosted package is not identical to the official one. I don't know whether this is due to incompetence or malice, but it is worrisome, as it may be possible that the maintainer has injected his own patches into the rehosted versions.
Thanks for bringing this up. I compared both versions of the tarball
(see diffoscope output attached) and, luckily, it appears that the only
things that differ in both binary versions are a build date embedded in
the binary and some metadata on the tarball.
Having said this, I think you're right, and I don't see a reason why
this tarball needs to be re-hosted.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the aur-general