[aur-general] The AUR package "svp" is suspicious
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...") # 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.
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...") # 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.
Hi Hirela,
Thanks for bringing this up. I compared both versions of the tarball (see diffoscope output attached)
Sigh, it appears it got scraped, here: https://paste.xinu.at/rTa Cheers, -Santiago.
On 6/29/19 5:18 PM, 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...") # 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.
Note that makepkg has a builtin mechanism for correctly versioning the sources. From man PKGBUILD(5): ``` It is also possible to change the name of the downloaded file, which is helpful with weird URLs and for handling multiple source files with the same name. The syntax is: source=('filename::url'). ``` The correct way to write a PKGBUILD for this software, then, is to download from the svp website, but rename the download to contain the version number. When updating the pkgver, the file will get redownloaded from the same location under a new name, and therefore not run into bad cache/checksum issues.
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.
-- Eli Schwartz Bug Wrangler and Trusted User
participants (3)
-
Eli Schwartz
-
Hirela
-
Santiago Torres-Arias