multiple malicious AUR updates

twelveeighty · Yesterday 14:35:46

Sidekick wrote:

Wait how can this happen? [...] I do not have the time for that.

You asked and answered your own question. Stop griping and demanding others to "some script needs to be created" and instead roll up your sleeves and help out. Arch is not social media where you can just sit back and thumb in some pointless witty remark post for likes & subscribes. Complaining isn't contributing, it's just pointless noise for a community driven distro.

LoNaAleim · Yesterday 14:43:11

It seems like the attacker is still "staging". The package has a pre-install hook but the current version of the package does not contain the file that is invoked there.

I have reported the package on npm.

M ~/c/lockfile-js-malware npm view lockfile-js@1.4.2 dist
{
  integrity: 'sha512-+2BE3pNMmUQBMmM+6MPRcS5CwpbLFWWo9Y+/+zrMzXeqpXHN6JopHJfBLm+k8jV4AD8SCKBjhShjD46QVr6COw==',
  shasum: 'db8382ec55803edbc9348dc53ec693295cc8266f',
  tarball: 'https://registry.npmjs.org/lockfile-js/-/lockfile-js-1.4.2.tgz',
  fileCount: 604,
  unpackedSize: 419254,
  signatures: [
    {
      keyid: 'SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U',
      sig: 'MEQCIF9sQ2iIDKavdKvzyRDJrO5UfVxPQAkEFbknLsSfnC7xAiBuqg3Ve7ddgQxsJj/fq794huWbVFbZUMgIJ6+yzt2pCQ=='
    }
  ]
}
M ~/code wget https://registry.npmjs.org/lockfile-js/-/lockfile-js-1.4.2.tgz
--2026-06-12 16:35:53--  https://registry.npmjs.org/lockfile-js/-/lockfile-js-1.4.2.tgz
Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt'
Resolving registry.npmjs.org (registry.npmjs.org)... 104.16.1.34, 104.16.6.34, 104.16.11.34, ...
Connecting to registry.npmjs.org (registry.npmjs.org)|104.16.1.34|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 96738 (94K) [application/octet-stream]
Saving to: ‘lockfile-js-1.4.2.tgz’

lockfile-js-1.4.2.tgz                   100%[============================================================================>]  94.47K  --.-KB/s    in 0.01s

2026-06-12 16:35:53 (6.18 MB/s) - ‘lockfile-js-1.4.2.tgz’ saved [96738/96738]
M ~/c/lockfile-js-malware shasum lockfile-js-1.4.2.tgz
db8382ec55803edbc9348dc53ec693295cc8266f  lockfile-js-1.4.2.tgz
M ~/c/lockfile-js-malware npm view lockfile-js@1.4.2 scripts
{
  build: 'tsc -p tsconfig.build.json',
  'build:esm': 'tsc -p tsconfig.esm.json',
  'build:cjs': 'tsc -p tsconfig.cjs.json',
  'build:types': 'tsc -p tsconfig.types.json',
  dev: 'tsc -p tsconfig.build.json --watch',
  test: 'node --experimental-vm-modules node_modules/.bin/jest',
  'test:unit': 'jest --testPathPattern=unit',
  'test:integration': 'jest --testPathPattern=integration',
  'test:coverage': 'jest --coverage',
  lint: 'eslint src/**/*.ts',
  'lint:fix': 'eslint src/**/*.ts --fix',
  format: 'prettier --write src/**/*.ts',
  'format:check': 'prettier --check src/**/*.ts',
  typecheck: 'tsc --noEmit',
  clean: 'rm -rf dist',
  prepublishOnly: 'npm run clean && npm run build',
  docs: 'typedoc --out docs src/index.ts',
  'docs:serve': 'serve docs',
  benchmark: 'node benchmarks/index.js',
  changelog: 'conventional-changelog -p angular -i CHANGELOG.md -s',
  preinstall: './lib/install-deps.mjs',
  release: 'npm run changelog && npm run build && npm publish'
}
M ~/c/lockfile-js-malware tar -tf lockfile-js-1.4.2.tgz | grep lib

seth · Yesterday 14:55:03

Fwwi, no script in the world will change anything about the fact that the AUR cannot be trusted.
It's a structured way for random dudes on the internet to share tips on how to install stuff.
It spares you the burden to come up w/ a PKGBUILD, but not the burden to understand it.

It is expected and mandatory to verify the PKGBUILD and the sources! yourself.

user109396 · Yesterday 14:58:09

I'm seeing malicious updates in non-orphaned packages as well. The attacker likely mined some packagers' credentials during the previous round.

darthvader · Yesterday 15:10:50

seth wrote:

Fwwi, no script in the world will change anything about the fact that the AUR cannot be trusted.
It's a structured way for random dudes on the internet to share tips on how to install stuff.
It spares you the burden to come up w/ a PKGBUILD, but not the burden to understand it.
It is expected and mandatory to verify the PKGBUILD and the sources! yourself.

while that maybe the case, but the ongoing registration of hundreds of new aur accounts who then adopt orphan packages to make these malicious commits should trigger a red flag somewhere... the arch linux gitlab repo has stopped account registrations, maybe time to do the same for the aur.

Whoracle · Yesterday 15:11:09

Maybe the powers that be can create a dummy squatter AUR user and batch-adopt all orphaned packages for the time being? Still doesn't fix those who had their creds exfiltrated, but should stop the brunt of it? At least would take the pressure off a little bit for finding a solution.

cryptearth · Yesterday 15:12:00

this reply may not fit here, hence @mods feel free to split off

not long ago two german tech media Golem and Heise warned about broad supply attacks to both python and node/js/npm - this looks related

when i read these news i already had the idea to post about it and how about to protect oneself against malicious packages
i started by checking my installed packages and started to clean out a lot - with all that remains from aur is self-built zfs from my own fork and icaclient for citrix which recently got pushed to remove the hard dependency on webkit2gtk-4.0, which according to citrix now comes bundled - thanks to whoever did the webkit2gtk-bin in the meantime to avoid long recompiling

i threw away pretty much everything related to "AI" (had llama.cpp installed from official source - but it has quite some build and runtime dependencies) - also had comfyUI as i experimented with image generation - but getting that to work is pretty much a minefield of trusting A LOT of random python and JS packages

Sidekick · Yesterday 15:18:31

Found this article: https://ioctl.fail/preliminary-analysis-of-aur-malware/ some key information that is useable for normal/advanced users is in there.

Some people wrote very unhelpful things in response to my comment. A little warning box on the landing page is absolutely meaningless to most users, especially when this landing page is directly linked and thus virtually endorsed on the official website of the distribution. Please stop debating this point as that isn't what this thread should be about and is not helpful. That is my opinion and you will not change it.

As for @twelveeighty's comment - You clearly didn't read my post in it's entirety or you chose to not understand it. Either way your post is nothing but irony as it is utterly pointless itself, doesn't add anything to this discussion and in no way helps other people. So congrats to making the internet a worse place.

Moving on.

Commands I used, based on the previously linked article, to determine if my system is affected:

npm -g list

to check if the atomic-lockfile package was installed.

ls -la ~/.local/bin/systemd

to check for newly installed systemd services on a user level and

ls -laR /etc/systemd/system

to check for newly installed systemd services on a system level.

grep -R 'RestartSec=30' /etc/systemd/system

to check for systemd services that might be installed and might not be visible to ls (see the bpf section that talks about hiding stuff) but would match the malware pattern. If someone knows how to do search for a linebreak in grep and add the other part to it, feel free. I tried and failed.

ls -la /sys/fs/bpf

check if any of the files described in the article are there.

Now the article does say that if bpf was modified some files might not be displayed by ls, so it would be best to do all these commands from a live USB stick/different computer while the system to check is shutdown, but given the two AUR packages I had installed during the past 2 weeks I'm fairly confident that I'm not affected, though it seems this wave has been going on for a bit. At least on the mailing list I can find entries from May in regards to a package called browsh-bin.

Last edited by Sidekick (Yesterday 15:32:31)

seth · Yesterday 16:05:37

Please stop debating this point as […] That is my opinion and you will not change it.

Convenient, but completely detached from reality.
https://wiki.archlinux.org/title/Arch_User_Repository has a warning and so has https://wiki.archlinux.org/title/AUR_helpers and

A little warning box on the landing page is absolutely meaningless to most users

doesn't prove you right but ignorant of reality.
Your "opinion" is simply wrong - the AUR is not, never has been and never will be trustworthy, whether you refuse to accept that or not. Reality is not what you choose it to be.

if bpf was modified some files might not be displayed by ls

Yes.

given the two AUR packages I had installed during the past 2 weeks I'm fairly confident that I'm not affected

With that premise, why check at all?

"I should be checking correctly whether I'm affected but I'm not affected therefore I'm checking sloppily whether I'm affected" is some trump-grade BS logic, neatly tying back into your refusal of the AUR nature.
Reality is not what you choose it to be.

If you're not sure whether you're affected, check this correctly.
If you're sure you're unaffected, why check at all?

If someone knows how to do search for a linebreak in grep

grep -RA1 'Restart=always' {/etc/systemd/system,~/.config/systemd/user/} | grep -B1 RestartSec=30

to check if the atomic-lockfile package was installed.

https://bbs.archlinux.org/viewtopic.php … 1#p2301001

Fwwi, 1280 has just pointed out that the intro of your post qualifies you for a mandatory review of https://www.youtube.com/watch?v=5RyYrs5tu60 (yes, it's the shouldland video…)

Sidekick · Yesterday 16:59:56

seth wrote:

Please stop debating this point as […] That is my opinion and you will not change it.
Convenient, but completely detached from reality.
https://wiki.archlinux.org/title/Arch_User_Repository has a warning and so has https://wiki.archlinux.org/title/AUR_helpers and
A little warning box on the landing page is absolutely meaningless to most users
doesn't prove you right but ignorant of reality.
Your "opinion" is simply wrong - the AUR is not, never has been and never will be trustworthy, whether you refuse to accept that or not. Reality is not what you choose it to be.

Given that you absolutely seem to need to engage in this and can't just leave this alone, here are the reasons that are the foundation of my opinion: AUR is publicly linked on the website of this project, it is right next to the Download button, it's style is the same as the Packages and the Download button. When clicking the link a page opens without a warning label or caution box. Compare this to the wiki where important informations/warnings are highlighted in a yellow/orange or even red box. Nothing there indicates that a) the text in the little box is important or b) that installing anything from there can harm your system. I understand that you are expecting users to always read all information on a webpage, but that is just wishful thinking and it's why on the wiki - and on most other websites and in most applications - important informations are highlighted with different colours, have boxes with different background colours around them and sometimes even need a user to click an 'OK I understand' button to continue. Note that that is not a call to action, I'm explaining why I had a different expectation of how the AUR worked and why I'm very certain that not a small number of new users probbably have the same impression of it.

given the two AUR packages I had installed during the past 2 weeks I'm fairly confident that I'm not affected
With that premise, why check at all?

because being 'fairly certain' and knowing something are two very different things? I'm not sure what you want to express with that question. There are, to me, a bunch of unknowns about this situation. Most of all when the attack actually started. Second is a full list of packages and versions affected. From what I was able to find there is no such list and I do not have the ability or the knowledge to craft one. I can help gather information and come up with simple scripts to evaluate if a system is affected based on information others have gather, like article I linked to before, but beyond that I am uncomfortable giving or providing advice as I'm neither a pentester nor someone with deeper knowledge about how an attacker might obfuscate their malicious code and files.

"I should be checking correctly whether I'm affected but I'm not affected therefore I'm checking sloppily whether I'm affected" is some trump-grade BS logic, neatly tying back into your refusal of the AUR nature.
Reality is not what you choose it to be.
If you're not sure whether you're affected, check this correctly.
If you're sure you're unaffected, why check at all?

why are you being so antagonistic? Where did I give you the impression that I was 100% sure I was unaffected? I'm still not 100% sure. Yes, all the digging around I did seems to indicate that my system isn't affected and the fact I only updated two AUR packages in the past week and none today or yesterday should make it extremely unlikely I'm affected but that's not proof.

If someone knows how to do search for a linebreak in grep
grep -RA1 'Restart=always' {/etc/systemd/system,~/.config/systemd/user/} | grep -B1 RestartSec=30

no wonder I couldn't make it work, thank you!

to check if the atomic-lockfile package was installed.
https://bbs.archlinux.org/viewtopic.php … 1#p2301001

ah, yes, checking for lockfile-js on top of the atomic-lockfile package, good call.

wonderworld · Yesterday 17:34:49

I used the script that checks for affected packages and their last update from:
https://github.com/lenucksi/aur-malware-check

Sadly one package was detected as problematic:

============================================================
 AUR Malware Check v2.1.0
 Campaign: atomic-lockfile / js-digest infostealer + eBPF rootkit
 Date window: 2026-06-09 to 2026-06-12
 Packages checked: 512
============================================================

--- [1] Currently installed foreign packages ---
  WARNING: 1 possibly infected package(s):
  - libquvi-scripts (installed: Tue Jun  9 19:25:30 2026)

--- [2] Historical pacman logs ---
LOG_HIT: libquvi-scripts (upgraded on 2026-06-09)
  WARNING: historical log matches:
  - libquvi-scripts (upgraded on 2026-06-09)

============================================================
 RESULT: INFECTED - Indicators found! Follow incident response.
============================================================

Afterwards I checked the AUR log for libquvi-scripts.
https://aur.archlinux.org/cgit/aur.git/ … vi-scripts

The last change was 2026-05-17 and I can't find any mention of atomic-lockfile in the PKGBUILD.

Am I safe here or do i miss something?
Did the problematic versions vanish from the logs maybe?
If yes how could I check if the change happened after 2026-06-09 (the date i upgraded the package)
Is there a way to find the used PKGBUILD on my local disk? Sorry I am not too experienced with AUR internals. I have been using yay for AUR.

Thanks a lot for any help!

Last edited by wonderworld (Yesterday 17:39:12)

loqs · Yesterday 17:49:33

@wonderworld are you sure using a third party script you can not follow to search for malicious activity is the best approach? The script appears to flag any package not installed from a repository since the start of the incident irrespective of the lack of other indicators.

V1del · Yesterday 17:50:27

yay has a ~/.cache/yay where the PKGBUILDs used reside.

Sidekick · Yesterday 18:10:16

Didn't look at the bash script, but the repository's readme links to the 'first report' on the mailinglist which is from yesterday and going by the links it seems the wave truly started on the 9th of June. That doesn't seem to match with the email I found from the 27th of May. Link: https://lists.archlinux.org/archives/li … E4QJAFJJ2M that indicates a that browsh-bin "now installs a sketchy npm package". Maybe that was some sort of 'test' by the attacker? But checking the AUR of that package I can't see that version so I guess the malicious commit was reverted. Could of course also be a completely different thing and that's just a coincidence.

Last edited by Sidekick (Yesterday 18:10:43)

wonderworld · Yesterday 18:10:18

Thanks. Sadly my yay cache is beeing autocleanedup and lost.
But I have /var/log/pacman.log

grep --text "upgraded libquvi-scripts" /var/log/pacman.log 
[2015-05-23 02:25] [ALPM] upgraded libquvi-scripts (0.9.20131130-2 -> 0.9.20131130-3)
[2018-06-11 00:54] [ALPM] upgraded libquvi-scripts (0.9.20131130-3 -> 0.9.20131130-4)
[2020-05-20T00:57:12+0200] [ALPM] upgraded libquvi-scripts (0.9.20131130-4 -> 0.9.20131130-5)
[2026-06-09T19:25:30+0200] [ALPM] upgraded libquvi-scripts (0.9.20131130-5 -> 0.9.20131130-6)

The current version in AUR is 0.9.20131130-6 and it's not compromised.
Would the infected version have the same version number?
As I understand the maintainers cleaned up the AUR.
Would the version number stay the same?

Sidekick · Yesterday 18:21:40

progandy wrote:

Sidekick wrote:
Wait how can this happen? Arch has a very good trusted user system - to the point where it has so far deterred me from getting involved as I do not have the time for that. How can some random accounts just push code changes *and* let those go live without any kind of review system in place?
Packages in the official repository are not affected, only a limited group of verified users (developers, trusted users and so on) can push there.
Someone is taking over orphaned AUR packages automatically and adding the malware. Orphaned means there is no maintainer for these packages and anyone with an AUR account can accept that maintainer role and submit updates.

Yeah I had made wrong assumptions about the AUR. Should've read the wiki about it. As for orphaned, the ALVR package in the AUR was also affected, so it's not just unmaintained packages. According to the waybackmachine the package had the most recent update in August 2025. So maybe it's not directly unmaintained packages but packages that haven't received an update in a long time and thus seem unmaintained?

Would the infected version have the same version number?
As I understand the maintainers cleaned up the AUR.
Would the version number stay the same?

good question. From what I've seen the infected version would be higher and when it is cleaned up they seem to just revert the git commit(s) so it looks like nothing ever happened to the package. I tried finding a package via web.archive.org when it was in an infected stage to see what that looked like and compare to the current, cleaned up state but so far no luck.

*edit*

finally found a git commit that I can link to and see: https://aur.archlinux.org/cgit/aur.git/ … 18ec5976fa that is the malicious commit, as can be seen the version number was not changed the package has been cleaned up and still has the same version number.

Also found a second mailinglist thread for the browsh-bin package: https://lists.archlinux.org/archives/li … 4GQPTTYAN/ in it Auerhuhn explains that she cleaned up the package by deleting the offending commit. I guess that means it was cleaned up differently to how the packages of the current attack waves have been cleaned up in.

Last edited by Sidekick (Yesterday 18:50:35)

wonderworld · Yesterday 18:48:15

OK, found it here:
https://github.com/archlinux/aur/compar … 76a658ac6e

Malware was injected on 2026-06-11.
Change was reverted on the same day.

The strange thing is I have a cronjob running for updates. It ran yesterday after the commit.
So the package should have been updated, but it doesn't show up in my pacman.log.

grep --text "upgraded libquvi-scripts" /var/log/pacman.log 
[2015-05-23 02:25] [ALPM] upgraded libquvi-scripts (0.9.20131130-2 -> 0.9.20131130-3)
[2018-06-11 00:54] [ALPM] upgraded libquvi-scripts (0.9.20131130-3 -> 0.9.20131130-4)
[2020-05-20T00:57:12+0200] [ALPM] upgraded libquvi-scripts (0.9.20131130-4 -> 0.9.20131130-5)
[2026-06-09T19:25:30+0200] [ALPM] upgraded libquvi-scripts (0.9.20131130-5 -> 0.9.20131130-6)

Now I am a bit out of ideas.
I searched files in /var/lib for the malwares SHA256 sum as stated here: https://ioctl.fail/preliminary-analysis-of-aur-malware/

Nothing. Really unsure what to do now. Any way to confirm if I have been infected or not?

wonderworld · Yesterday 18:50:52

*edit*
finally found a git commit that I can link to and see: https://aur.archlinux.org/cgit/aur.git/ … 18ec5976fa that is the malicious commit, as can be seen the version number was not changed the package has been cleaned up and still has the same version number.

Thank you. bad news.

Sidekick · Yesterday 18:53:41

wonderworld wrote:

OK, found it here:
https://github.com/archlinux/aur/compar … 76a658ac6e
Malware was injected on 2026-06-11.
Change was reverted on the same day.
<snip/>
Nothing. Really unsure what to do now. Any way to confirm if I have been infected or not?

No, your link actually confirms what I described in my edit of my previous post: The version numbers are apparently not changed by the attackers, maybe to make it less apparent that something was changed? You can see that even in the commit, at the top of the diff you can see that the before and after have the same version number "pkgver" and "pkgrel" are the relevant fields and they are unchanged. That also, of course, explains why your package manager didn't pick it up. You should be fine if that was the only concerning package.

Last edited by Sidekick (Yesterday 18:54:26)

wonderworld · Yesterday 18:56:53

No, your link actually confirms what I described in my edit of my previous post: The version numbers are apparently not changed by the attackers, maybe to make it less apparent that something was changed? You can see that even in the commit, at the top of the diff you can see that the before and after have the same version number "pkgver" and "pkgrel" are the relevant fields and they are unchanged. That also, of course, explains why your package manager didn't pick it up. You should be fine if that was the only concerning package.

Thanks for the insight. That sounds good. But this way only people who would do a fresh install of the package would ever run into problems?

Sidekick · Yesterday 19:01:01

wonderworld wrote:

No, your link actually confirms what I described in my edit of my previous post: The version numbers are apparently not changed by the attackers, maybe to make it less apparent that something was changed? You can see that even in the commit, at the top of the diff you can see that the before and after have the same version number "pkgver" and "pkgrel" are the relevant fields and they are unchanged. That also, of course, explains why your package manager didn't pick it up. You should be fine if that was the only concerning package.
Thanks for the insight. That sounds good. But this way only people who would do a fresh install of the package would ever run into problems?

I think so? Which is kind of a weird attack vector, but maybe the attacker(s) didn't know that commiting something would trigger emails and were hoping their changes would go mostly unnoticed. Maybe this is only true for a few packages and for others they increased the version number? I've also not checked any of the "wave 2" packages and if the npm -> bun change is the only difference.

*edit*
These two commits show malicious bun calls, meaning they are part of "wave 2" and neither of them changes the version number.
https://aur.archlinux.org/cgit/aur.git/ … ad6b18dbe9
https://aur.archlinux.org/cgit/aur.git/ … 0d34c9b31b

I just saw that the pkgversion is tied to the source and that is tied to the hashsum in the pkgversion file, that's why they can't just modify that.

Last edited by Sidekick (Yesterday 19:58:06)

wonderworld · Yesterday 19:11:40

Sidekick wrote:

I think so? Which is kind of a weird attack vector, but maybe the attacker(s) didn't know that commiting something would trigger emails and were hoping their changes would go mostly unnoticed. Maybe this is only true for a few packages and for others they increased the version number? I've also not checked any of the "wave 2" packages and if the npm -> bun change is the only difference.

This would be good news, if this is the case for all modified packages. Would reduce the damage massively.
This was a stressful friday afternoon so far.

silensys · Yesterday 21:09:41

I have multiple ideas to prevent similiar incidents happening and keeping the bad actors out in the future, so I'll quickly list them here before I forget:

1. make a reputation system for users, so that they would have either good or bad reputation, in regard of what they do, if they do useful things they have good reputation (trusted), if they do shady stuffs they will have a bad reputation (untrusted) and be blocked from any further actions, get their account suspended, and permabanned via IP + mail; Fresh registrations will have also untrusted level, regardless they didn't do anything wrong, but it is what it is, they will earn their trust level step by step. Reputation starts at 0 and is earned by points. Good commit: +1pts, Bad commit: -2pts. That's right. One shady step and they're two steps back! Now, I'd say that having accumulated like, 50pts would do the trick to step into the trusted phase. Continuous bad commits even while in trusted state would trigger a redflag and block the user from committing until manual inspection.

2. If a package goes orphan only let trusted people adopt it, with at least TEN consecutive reputation gains (commits) being positive!

3. manual review commits from people with lower reputation levels.

4. implement validating system, and if a package changes maintainer then devalidate it server side (in a read-only fashion), aur helpers could then query this via API for example, and warn user when they get an upgrade that there was a major impact on package (maintainer swap should be a default huge redflag)

5. don't let newly registered people adopt orphaned packages, this I will make subsections:
5.1 if a user is 3months or newer, system would not allow them to adopt packages, instead it would submit a ticket to AUR mods for manual inspection.
5.2 AUR mods would review this application, and here they can already find out if it's suspicious, especially when they requested a lot of adoptions from the same account or from different accounts but in a short span of time period - (spamming adoptions)

6. If someone registers fresh and isn't active at all, that should be also a redflag somehow, as they might be attempting to have as many alias accounts as they can for their next attack waves in reserve! If someone registers, and doesn't do anything in the upcoming weeks or months, put a flag on their account, as potential pre-attack plans. Only way they can get back their active status is by submitting a ticket to mods, and mods will decide whether they want to activate it back, but it adds an extra layer of security.
6.1 this opens to another idea: activity system.

So in conclusion: People who are active + have good reputation (trusted) are very okay.
People who newly register are very very untrusted strangers, aliens, UFOS, UAPS, and they will start build themselves from the rock bottom, climbing the highest of mountains, making it challenging for them to earn their trust. If they have good activity + good reputation, they are welcome. If they have zero activity and zero trust, or many activity but with negative reputation (untrust) can enjoy the wrath of the banhammer + go somewhere else, maybe touch the grass, and think about their actions, twice ...or countless.

Sorry if this was a bit chaotic, I wanted to send this in as fast as possible, because time is of the essence.
These points are an as-is, put a bit more imagination into it, combine it with each other, fine-tune it. In the end, I hope I started something and gave Arch community a spark to light an idea.

Stay safe, be always on the alert, stay in the light, and banish the shadows!

Last edited by silensys (Yesterday 21:24:04)

seth · Yesterday 21:25:06

1. who hands out the reputation points? How is this secure against abuse (brigading)?
2. what happens if a trusted account gets breached (poor password or victim to an exfiltration campaign) and silently abused? You won't check the PKGBUILD of a trusted user, will you?
3. what happens if upstream is compromised? What if it gets compromised after the "good commit" (which is now a bad one)?

The AUR is not trustworthy and cannot be w/o stopping to be the AUR.
The PKGBUILDs there are suggestions/inspirations to build a package.

It is *not* just the ridiculously most inefficient official repo for users to use on autopilot and "AUR helper" is exactly what's wrong in this equation.
You *have* to vet the build. Every. Single. Time.

silensys · Yesterday 21:37:03

@seth

1. automated-system hands out the points and secure against abuse via combining it with further manual interventions, thats why I said the list I made can be combined + put more imagination into it, that's the only limit.
2. Fair enough! Please do share your idea of how to solve that problem, because you clearly have one, don't you?
3. that's also a good point, but rare, plus that's the whole point, if the upstream is compromised then our trusted aur maintainers would vet it anyways, and the ones who are new are untrusted by default so they can't trick it in, that's my whole idea after all with all the manual AUR mod inspections / interventions in conjunction to automated systems...

Yes, you are right, AUR is not trustworthy, I shared these ideas to reduce the malicious submissions to AUR to a minimum level, there's no 100% safe system, but basic preventions should be implemented, like, new registered users seriously shouldn't be able to adopt packages...

> "You *have* to vet the build. Every. Single. Time."

Correct, but still, reducing the attack vectors to a minimum is the best way to prevent such things to happen. Ever. Again.

Arch Linux

#26 Yesterday 14:35:46

Re: multiple malicious AUR updates

#27 Yesterday 14:43:11

Re: multiple malicious AUR updates

#28 Yesterday 14:55:03

Re: multiple malicious AUR updates

#29 Yesterday 14:58:09

Re: multiple malicious AUR updates

#30 Yesterday 15:10:50

Re: multiple malicious AUR updates

#31 Yesterday 15:11:09

Re: multiple malicious AUR updates

#32 Yesterday 15:12:00

Re: multiple malicious AUR updates

#33 Yesterday 15:18:31

Re: multiple malicious AUR updates

#34 Yesterday 16:05:37

Re: multiple malicious AUR updates

#35 Yesterday 16:59:56

Re: multiple malicious AUR updates

#36 Yesterday 17:34:49

Re: multiple malicious AUR updates

#37 Yesterday 17:49:33

Re: multiple malicious AUR updates

#38 Yesterday 17:50:27

Re: multiple malicious AUR updates

#39 Yesterday 18:10:16

Re: multiple malicious AUR updates

#40 Yesterday 18:10:18

Re: multiple malicious AUR updates

#41 Yesterday 18:21:40

Re: multiple malicious AUR updates

#42 Yesterday 18:48:15

Re: multiple malicious AUR updates

#43 Yesterday 18:50:52

Re: multiple malicious AUR updates

#44 Yesterday 18:53:41

Re: multiple malicious AUR updates

#45 Yesterday 18:56:53

Re: multiple malicious AUR updates

#46 Yesterday 19:01:01

Re: multiple malicious AUR updates

#47 Yesterday 19:11:40

Re: multiple malicious AUR updates

#48 Yesterday 21:09:41

Re: multiple malicious AUR updates

#49 Yesterday 21:25:06

Re: multiple malicious AUR updates

#50 Yesterday 21:37:03

Re: multiple malicious AUR updates

Board footer