juicefs-cloud

maintainer Sasasu · 1 votes · scanned 2026-08-03 00:08:14.047287
MEDIUM
View on AUR ↗
Why flagged The PKGBUILD downloads a prebuilt binary directly from juicefs.com/static/juicefs — a URL that has no version component, meaning it always fetches whatever the current binary is at that path, regardless of pkgver. While juicefs.com is the official vendor domain, the URL is a static/unversioned endpoint that could silently serve a different binary at any time. The sha512sum is present and non-SKIP, which provides some integrity guarantee for the specific binary captured at packaging time, but since the URL is unversioned, any future build or re-download could fetch a different binary with a different hash (causing a build failure or, if the hash were SKIP, silently installing a different binary). The binary is installed as an executable in /usr/bin. The core concern is: executed binary from an unversioned URL on the vendor's own domain, with a pinned checksum that only protects the initial fetch. This is a real but moderate supply-chain concern — not clearly malicious, but the unversioned URL pattern means the checksum provides weaker-than-usual protection. Rated medium.

Triggered rules

MEDIUM source=() URL on a non-standard host source_untrusted_domain

One or more source=() URLs point to a host outside the trusted allowlist (github.com, gitlab.com, codeberg.org, pypi.org, …).

  • PKGBUILD:11 source=("juicefs-$pkgver-$pkgrel::https://juicefs.com/static/juicefs")
MEDIUM AI review llm_review

An AI model (anthropic/claude-4.6-sonnet-20260217) reviewed this and agrees it is MEDIUM (confidence 82%): The PKGBUILD downloads a prebuilt binary directly from juicefs.com/static/juicefs — a URL that has no version component, meaning it always fetches whatever the current binary is at that path, regardless of pkgver. While juicefs.com is the official vendor domain, the URL is a static/unversioned endpoint that could silently serve a different binary at any time. The sha512sum is present and non-SKIP, which provides some integrity guarantee for the specific binary captured at packaging time, but since the URL is unversioned, any future build or re-download could fetch a different binary with a different hash (causing a build failure or, if the hash were SKIP, silently installing a different binary). The binary is installed as an executable in /usr/bin. The core concern is: executed binary from an unversioned URL on the vendor's own domain, with a pinned checksum that only protects the initial fetch. This is a real but moderate supply-chain concern — not clearly malicious, but the unversioned URL pattern means the checksum provides weaker-than-usual protection. Rated medium.

PKGBUILD

1 offending line(s) highlighted
1# Maintainer: Sasasu <sasasu [at] archlinuxcn.org>
2
3pkgname=juicefs-cloud
4pkgver=4.9.11
5pkgrel=1
6pkgdesc="A shared POSIX file system for the cloud"
7arch=('i686' 'x86_64')
8url="https://juicefs.com/"
9license=('custom')
10depends=('python')
11source=("juicefs-$pkgver-$pkgrel::https://juicefs.com/static/juicefs")
12sha512sums=('c4bfcb9c8e8a019b96ec34638e2180b1f87f87c448a6d7e1a91ee42dee32c0ffb3a038928a9d2671aa1c59f2a8217d29797182f3de51680845d12752eb14514e')
13
14build() {
15 cd "${srcdir}/"
16}
17
18package() {
19 cd "${srcdir}/"
20 install -Dm755 "${srcdir}/juicefs-$pkgver-$pkgrel" "${pkgdir}/usr/bin/juicefs"
21 ln -s "/usr/bin/juicefs" "${pkgdir}/usr/bin/mount.juicefs"
22}
23

Scan history

Scanned at (UTC)SeverityRules
2026-08-03 00:08:14 MEDIUM 2
2026-08-02 00:16:08 MEDIUM 2
2026-08-01 00:11:18 MEDIUM 2
2026-07-31 00:14:10 MEDIUM 2
2026-07-30 00:17:23 MEDIUM 2
2026-07-29 00:25:53 MEDIUM 2
2026-07-28 00:07:28 MEDIUM 2
2026-07-27 00:24:32 MEDIUM 2
2026-07-26 00:07:32 MEDIUM 2
2026-07-25 00:13:44 MEDIUM 2
2026-07-24 00:02:28 MEDIUM 2
2026-07-23 00:14:47 MEDIUM 2
2026-07-22 00:29:32 MEDIUM 2
2026-07-21 00:24:15 MEDIUM 2
2026-07-20 00:19:49 MEDIUM 2
2026-07-19 00:17:08 MEDIUM 2
2026-07-18 00:14:48 MEDIUM 2
2026-07-17 00:06:16 MEDIUM 2
2026-07-16 00:05:41 MEDIUM 2
2026-07-15 00:09:25 MEDIUM 2

Report a package

Reports go to the AURWatch maintainer (one person) and are read by hand. No login required.

0 / 4000
Your suggestion