[aur-general] The AUR package "svp" is suspicious

[Hirela]

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 4.3.0.165:

    pkgver=4.3.0.165
    source=("https://gist.githubusercontent.com/phiresky/1e2cbd30bed4e5978771af232d11afd1/raw/svp4-$pkgver.tbz2")
    # 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
    sha256sums=('00a025ce7c06660bafbad8cf5d889e9a6f09a9c9c9585dbee2415a8bf0256f53')

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 (4.3.0.165) 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.