Package Details: y-cruncher

Git Clone URL: (read-only, click to copy)
Package Base: y-cruncher
Description: The first scalable multi-threaded Pi-benchmark for multi-core systems
Upstream URL:
Licenses: custom
Submitter: kfgz
Maintainer: eclairevoyant
Last Packager: eclairevoyant
Votes: 13
Popularity: 0.104795
First Submitted: 2010-11-17 10:40 (UTC)
Last Updated: 2024-04-01 21:40 (UTC)

Latest Comments

1 2 3 Next › Last »

harre commented on 2023-10-17 22:04 (UTC)

A new version is out and old seems to be removed so trying to install this package yields an 404 error now.

eclairevoyant commented on 2023-01-02 02:03 (UTC)

I've updated this to use the dynamically linked binary. Checking with ldd and some cursory tests seem to find no issues with dependencies atm, but let me know if I've missed anything.

ipaqmaster commented on 2022-12-11 00:22 (UTC)

Thanks for stepping up for this package

eclairevoyant commented on 2022-12-11 00:21 (UTC)

Adopted and updated. Will look into using the dynamically linked version of the binaries as that has more features, and hopefully upstream can provide package signing in future releases.

ipaqmaster commented on 2022-11-24 21:02 (UTC) (edited on 2022-11-24 23:14 (UTC) by ipaqmaster)

Many projects and *-git projects on the AUR use 'SKIP' where they have the luxury of pulling from a https/ssh git repository and often verify signatures further. (Not always though). This software provides absolutely zero way to verify the download, on top of having a broken HTTPS setup not even providing the bare minimum.

It's really not that hard to keep track of the releases and update accordingly.

I agree, but neither you or I can push an update to this package and we would be generating the sha512 sum for new releases from the same insecure http source anyway... Any number of mitm attacks could be used to inject malware between your machine and the website during your sha512sun generation. Even just DNS record swap to an attacker's dangerous tar.xz download platform. Or the website could get compromised and distribute tainted tar.xz package which would be a more realistic case for a matching sha512sum in an AUR package update which doesn't actually verify the package itself, only the file integrity. We need developer support here such as providing a pgp signature to verify these downloads.

It's a bad idea not to verify something but the developer doesn't actually provide any verification for these downloads and is 404ing the older versions which we already established a checksum of at their time of release (Which could at least detect future tampering of the same download), but their 404ing of old versions breaks this AUR package immediately.

Their site has HTTPS support but uses a self signed cert which expired mid 2020. Right now there is literally no truly secure way for us to handle this package. We could ignore the https problem and continue using http safely if they provided a .sig file alongside their releases for us to not only verify the downloaded tar.xz isn't corrupted, but also hasn't been tampered with. That may be a tall order though, but our current zero verification does give an attacker a potential way into an Archlinux host wishing to install y-cruncher from the AUR.

Any suggestions outside waiting for this AUR package to either get an update or become orphaned so we can push a pkgver + sha512sum to it ourselves? We're mostly of at the developer's mercy with verifying and safely downloading this one.

at least use the pkgver() function...

Yeah I tried a few times initially but makepkg kept trying the old pkgver variable and omitting it caused errors. Gave up and embedded it in the variable set as a subshell. The archwiki doesn't mention any mention anything about this problem for pkgver() so I'll leave the below snippet setting the variable with a subshell as at least that way it's being processed, and in order.

As it stands, until the developer provides, say... pgp signatures for each of these new tar.gz releases this whole http situation isn't secure from the get-go.

eclairevoyant commented on 2022-11-24 17:13 (UTC)

Using SKIP is a terrible idea. It's really not that hard to keep track of the releases and update accordingly.

Also if you're going to use a script to generate pkgver, at least use the pkgver() function...

ipaqmaster commented on 2022-11-23 23:24 (UTC) (edited on 2022-11-23 23:55 (UTC) by ipaqmaster)

Which is why I also suggested -latest as a suffix. (You may have replied before my edit) but realistically there's no reason this AUR package cannot just fetch the latest.

I do not see any checksum of these releases official from the developer on their distribution site here for automatic verification so I made an issue here to see if they may be willing to provide one with releases officially, otherwise automatic version detection will need to have sha512sum set to ('SKIP')

The below dirty looking diff worked on my laptop with a fresh git clone of this AUR package, git apply of this diff and makepkg by dynamically looking up the latest release from their website if anyone would like to try it:

diff --git a/.SRCINFO b/.SRCINFO
index e0ff428..bb32864 100644
--- a/.SRCINFO
+++ b/.SRCINFO
@@ -8,6 +8,4 @@ pkgbase = y-cruncher
    depends = gcc-libs
    options = !strip
    source =
-   sha512sums = f9747773cb5bbbf5e09513860db69d43a1d7fef654705b988a3def6e3ef93c9e3a347082933dca61791730809205fe388ecc4683254c5c0082f432faadcec96f
-pkgname = y-cruncher
+  pkgname = y-cruncher
diff --git a/PKGBUILD b/PKGBUILD
index cb90ca2..7fbf873 100644
@@ -3,17 +3,20 @@
 # Contributor: thesqrtminus1  <thesqrtminus1 at gmail dot com>
 # Contributor: kstolp <kevinstolp at gmail dot com>
 # Contributor: kfgz <ffiasd at gmail dot com>
+# Contributor: Jared Johnstone <jared at jjgaming dot net>
 pkgdesc="The first scalable multi-threaded Pi-benchmark for multi-core systems."
+pkgver="$(curl -G -s "${url}" |grep -Po -m1 '(?<=\>)y-cruncher.+tar.xz' | grep -m1 -Po '(?<=v)([0-9]+|\.)+')"
+pkgfilename="y-cruncher v${pkgver}-static.tar.xz"
+packageurl="$( sed 's/ /%20/g' <<< ${url}${pkgfilename})"
 package() {
 install -D -m755 ${srcdir}/y-cruncher\ v${pkgver}-static/Binaries/"05-A64 ~ Kasumi" ${pkgdir}/usr/bin/y-cruncher

eclairevoyant commented on 2022-11-23 22:58 (UTC)

@ipaqmaster It's not pulled from a git repo, so calling it -git makes no sense

ipaqmaster commented on 2022-11-23 22:37 (UTC) (edited on 2022-11-23 22:58 (UTC) by ipaqmaster)

This is a much smaller diff seemed to cause less issues for my git-apply.

diff --git a/PKGBUILD b/PKGBUILD
index cb90ca2..ad475be 100644
@@ -4,7 +4,7 @@
 # Contributor: kstolp <kevinstolp at gmail dot com>
 # Contributor: kfgz <ffiasd at gmail dot com>
 pkgdesc="The first scalable multi-threaded Pi-benchmark for multi-core systems."
@@ -13,7 +13,7 @@ license=('unknown')
 package() {
 install -D -m755 ${srcdir}/y-cruncher\ v${pkgver}-static/Binaries/"05-A64 ~ Kasumi" ${pkgdir}/usr/bin/y-cruncher

Given the nature of's tar.xz's for this closed source package (404ing old versions) y-cruncher should probably be made into a y-cruncher-git or more accurately a y-cruncher-latest AUR which automatically fetches the latest xz form their site regardless of version.

This bash one-liner is capable of fetching the current/latest .tar.xz filename from their site for any given latest version curl -s |grep -Po '(?<=\>)y-cruncher.+tar.xz'. This method can also be used to dynamically derive the pkgver variable.

I cannot see anywhere they provide a checksum however and deriving that from the source file would not be "safe" all potential automation considered.