On 6/13/26 1:43 AM, Ralf Mardorf wrote:
On Sat, 2026-06-13 at 01:23 -0500, David C Rankin wrote:
You should add a "rep" for each AUR user. For each review the user
should gain, e.g. +1 for the effort. Any review failure should cost,
e.g. -50 and result in account suspension for X? days.
Hi David,
we usually see eye to eye, but in this case we couldn't agree less.
Point made.
What I've distilled from all the suggestions, that would help with
the AUR issue, not some other attack, and not protecting against the
infinitely patient bad-guy, boils down to two possibilities:
1. A waiting period for adoption.
(7, 14, 21, 30, whatever days, packages with npm/pypi/etc get
manual review)
2. Review of the first X number of commits.
(if just by script added to the workflow that checks keywords)
The why not add (2) for all commits if it is not resource intensive.
This doesn't prevent the infinitely patient bad-guy from waiting out the
waiting period before deploying the malware, but they would still be
caught by (2) if it does a good job.
Nothing will be perfect, but if we can cut at 1600 package attack
down to a 20 package attack, we've gone a long way toward protecting
users and protecting AUR.
This preserves AUR in it's current form with wide-open anonymous
account registration but adds some guardrails against a mass attack to
make AUR a less-inviting target. Further, (1) and (2) can simply be
added to the workflow and do not require our non-existent
human-in-the-loop.
Though I still think the human-in-the-loop is the Cadillac version,
(1) and (2) are doable and would help.
I talked with the SUSE/openSUSE folks about what prevents the same
thing from happening to OBS (see opensuse-factory list thread "How
secure is OBS against package poisoning and which list to ask on?")
The big differences are the OBS account and no orphan pool. Nothing
prevents an OBS user from uploading a malicious file to their OBS
account, but there are no anonymous OBS accounts. The only way the
poisoning and upload would occur is (1) a malicious account got by the
SUSE registration process, or (2) an existing OBS user's account was
compromised. In either case the "scale" is limited to a one-at-a-time issue.
Nothing in the AUR or OBS case protects against a poisoned upstream
source. If we are thorough with the script in (2) above and had it scan
the sources as well to flag keywords there, that could be mitigated to a
degree. In the AUR case, any source scanning would have to be added as
part of the makepkg process, and compute required would just be part of
the build process if something like that is even doable. With OBS that
can occur as part of the build since the build is carried out by OBS,
not on the user's machine.
Even if (1) and (2) only cut the malware by 1/2, that's a lot of
moderator time and user risk avoided.
--
David C. Rankin, J.D.,P.E.
