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 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.
Hi Hirela, 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. Thanks, -Santiago.
signature.asc
Description: PGP signature
