Home   2026-08-03 17:31:33

←

Arch Linux-gebruikerspackages zijn tijdelijk afgesloten vanwege malwareaanval

Original article

De ontwikkelaars achter Arch Linux hebben de mogelijkheid om packages in de Arch Linux User Repository te 'adopteren' en bij te werken tijdelijk uitgeschakeld vanwege een grootschalige malwareaanval. Het is de tweede aanval in korte tijd. De ontwikkelaars geven op dit moment nog weinig informatie over de aanval.

Arch-ontwikkelaar Robin 'Antiz' Candau schrijft in een korte mailinglijst dat package adoption in de AUR tijdelijk is uitgeschakeld. Dat doet het team vanwege 'een toestroom aan malafide package adoptions en daaropvolgende commits via de AUR'.

Wat is de AUR?

Arch Linux heeft een eigen zogenaamde User Repository, de AUR. Daarin staan packages die bijvoorbeeld niet meer actief worden onderhouden of die maintainers zelf hebben vrijgegeven aan de community. Ontwikkelaars kunnen het beheer van zo'n package overnemen. Dat proces heet 'package adoption'.

Arch Linux

De nieuwe maintainer moet onder andere bouwen vanaf de pkgbuild. Dat is een Bash-script waarin instructies staan voor het installeren van Arch-packages. In Arch bevat een pkgbuild vaak niet de package zelf, maar een downloadlink naar een externe server waarvandaan de package wordt gedownload.

Dat maakt een aanval op de AUR aantrekkelijk voor hackers. Eindgebruikers moeten namelijk in principe de pkgbuild controleren voordat ze het script uitvoeren, maar in de praktijk doen veel gebruikers dat niet. Als een aanvaller een package in de AUR heeft 'geadopteerd' en er kwaad mee wil doen, kan die pkgbuilds aanpassen en ervoor zorgen dat gebruikers iets binnenhalen van een geïnfecteerde server. Dat lijkt nu te gebeuren, al zeggen de Arch-ontwikkelaars niet wat er precies aan de hand is.

Tweede aanval in korte tijd

Het is de tweede keer in korte tijd dat Arch wordt aangevallen, btw. Dat gebeurde in juni ook al. Toen sloten de ontwikkelaars de registratie van nieuwe AUR-accounts tijdelijk vanwege een malwarecampagne via geïnfecteerde packages. Aanvallers wisten toen zeker 1500 packages te infecteren.

Door Tijs Hofmans

Nieuwscoördinator

Feedback • 31-07-2026 20:59
73 • submitter: GertMenkel

31-07-2026 • 20:59

73

Submitter: GertMenkel

Lees meer

Reacties (73)

@TijsZonderH als ik dit lees dan klopt de titel
Arch Linux-gebruikerspackages zijn tijdelijk afgesloten vanwege malwareaanval
en de zin
De ontwikkelaars achter Arch Linux hebben de Arch Linux User Repository tijdelijk offline gehaald
niet. De AUR is helemaal niet offline, enkel de optie tot package adoption is uitgeschakkelt. De AUR offline halen zou wel echt véél ingrijpender zijn. Naast dat men dan geen nieuwe packages via de AUR zelf binnen kan halen, zouden veel mensen ook updates missen (gezien veel die laten checken via de AUR en men over het algemeen niet handmatig de software zelf checkt voor updates). Schrok dan ook toen ik de titel las, maar daar is gelukkig geen sprake van.

aur.archlinux.org lijkt vooralsnog online, en de PKGBUILDs die daarop staan beschikbaar.
edit:
Edit (dank aan @Nielssss): zie nu dat naast package adoption ook het pushen van nieuwe versies van packages uit is gezet. Nogsteeds niet hetzelfde als de AUR offline halen maar wel stuk ingrijpender dan enkel package adoption uitzetten. Hopelijk dat probleemgevallen snel opgelost worden en iig updates weer mogelijk worden.

[Reactie gewijzigd door Cambionn op 1 augustus 2026 17:26]

Oh dat is idd wel een stum ingrijpender. Nogsteeds niet gelijk hetzelfde als offline halen maar idd wel een stuk meer dan dit Tweakers artikel deed vermoeden. Thanks voor de verbetering!
Zitten er ook geen checksums of andere dergelijke dingen op Arch Debian heeft dit bijvoorbeeld wel. Al voert langs niet iedereen die uit.
De PKGBUILD, wat dus enkel een install script is die vaak de bestanden van source binnenhaalt en die je altijd dient te controlleren, bevat ook de regels voor je checksum. Tenzij je daarin expliciet zegt de checksums te skippen worden die uitgevoerd en als hij niet matched wprdt software niet geinstaleerd. Maar je moet wel ff kijken of de checksum in de PKGBUILD matched met de officiele bron, anders kan een malicious maintainer gewoon iets erin zetten dat matched met zijn malicious spul.

Voor de officiele Arch developers zijn er ook keys in de keyring. Als packages niet gesigned zijn door een developer in de keyring werkt het ook niet. Maar het punt van een user repository is dat users daar zelf in kunnen uploaden, dus tenzij je blind iedereens key gaat vertrouwen (wat ook het punt verbreekt) heb je daar weinig aan voor de AUR.

Het punt blijft uiteindelijk dat de AUR net zo behandeld dient te worden als andere random dingen installeren van de rest van het internet. Het is een plek om install scripts te delen waardoor je als community makkelijk elkaar kan helpen ipv dat iedereen zelf overal een eigen PKGBUILD voor moet bedenken, en die hulp makkelijk vindbaar te maken. Maar verder is het niet betrouwbaarder dan bijv. alles vanaf de release page van github installeren. Sterker nog, de AUR draait ook op git, en elk package erin is gewoon een git repro met een install script (de PKGBUILD) en eventuele extra bestanden.

Probleem is vooral dat men wel snapt dat je niet zomaar .exe's die je random online vond moet uitvoeren op je Windows (oké niet iedereen snapt dat, maar gaat nu ff om de mensen die dat wel snappen), maar men niet snapt dat dat blind doen met user-made install scripts net zo gevaarlijk is. Gemak dient de mens, en AUR helpers zijn leuk. Maar zonder enige check alles uitvoeren is gewoon niet slim, en puur omdat het met een AUR helper kán zegt niet dat je dat dan maar moet doen. (AUR helpers worden overigens niet door Arch zelf gemaakt worden, die raad ze zelfs af en raad aan handmatig te builden. Ze worden gemaakt door de community).

Dit soort dingen is dus ook waarom men zegt dat Arch niet een distro voor beginners is. Het installeren en enigsinds laten draaien is de moeite niet. Het daadwerkelijk stabiel en veilig houden vereist echter dat je zelf een beetje snapt hoe alles werkt en dat je dat bijhoud. De benodigde kennis en inzicht of dingen een goed idee zijn mist vaak bij beginners, en dan gaat het mis. Dat is niet bedoeld als elitisme, maar eerder ter bescherming van de gebruikers zelf (en tbh, ik snap ook niet waarom het idee dat niet alles voor beginners is zo'n issue is voor sommige mensen. En er zijn ook genoeg distros die juist wel op beginners focussen, dus Linux blijft gewoon toegankelijk).

[Reactie gewijzigd door Cambionn op 1 augustus 2026 13:24]

Jawel maar dit is een 2de package repository beschikbaar voor alle arch based distro's en daarbij gezien de aard van de reposerory moet je altijd goed uitkijken wat je van de aur af haalt. In principe unsupported packages om reden xyz

Hier vind je vaak ook packages die zo nieuw zijn dat ze nog niet door de distro's zijn opgepakt.

Het is dus fijn dat het er is maar niet zonder zijn gevaren. En als je niet weet wat je doet moet je enkel de packages van de distro repro afhalen
Op het AUR worden geen packages gedeeld, maar de scripts om packages te bouwen. Je krijgt het recept, en het is aan de eindgebruiker om valideren of dit recept veilig is of niet.

Dit staat ook helemaal los van de normale pacman package repositories, daar is alles gesigneerd met PGP door vertrouwde gebruikers, en worden packages kant-en-klaar aangeleverd.
Uiteraard gebruikt ook Arch dat, niet alleen voor de normale repo's, ook voor de hier genoemde AUR repo's. De benodigdheden voor een te bouwen AUR installable hebben een checksum.
AuteurTijsZonderH Nieuwscoördinator @Cambionn • 3 augustus 2026 09:47
Ik worstelde een beetje met de titel (damn die 80 tekens), want je hebt gelijk dat het niet helemaal offline is maar je kunt er praktisch niks mee. Ik weet niet zo heel goed hoe ik het beter kan verwoorden, jij een suggestie?
je hebt gelijk dat het niet helemaal offline is maar je kunt er praktisch niks mee
Nouja, voor update checks and auto-updaten kun je hem nu idd niet gebruiken. Maar software die weinig update kun je alsnog zo de laatste versie van installeren. En voor veel packages is de PKGBUILD zelf ff updaten naar de nieuwste versie niet zo moeilijk, dus het blijft ook een goede reverentie.
Ik weet niet zo heel goed hoe ik het beter kan verwoorden, jij een suggestie?
Ik heb ff zitten puzzelen :P.
Wat dacht je van de titel: "Arch Linux-userpackages worden tijdelijk niet geüpdatet vanwege malwareaanval"

En voor de eerste zin dan:
"De ontwikkelaars achter Arch Linux hebben de mogelijkheid om packages the adopteren en updates to pushen naar de Arch Linux User Repository tijdelijk uitgezet vanwege een grootschalige malwareaanval."
AuteurTijsZonderH Nieuwscoördinator @Cambionn • 3 augustus 2026 10:44
weet je wat, dat vind ik een goede suggestie en het past ook nog eens!
offtopic:
also jij kunt m'n arch-meme in het stuk wel waarderen toch

[Reactie gewijzigd door TijsZonderH op 3 augustus 2026 10:44]

Cool! Maar weet je, ik begin zelfs te twijfelen of dat wel klopt. Hoewel de mailing list idd zegt dat pushes zijn gedisabled, zijn packages gewoon geupdatet. Zelfs als ik terug ga naar oudere datums, heeft dat geen dag stil gelegen.

Wellicht dat er bedoeld werd dat enkel nieuwe packages niet gepushed konden worden, of dat newly adopted packages niet konden pushen. Of wellicht dat een lijst met trusted contributors nog wel toegang heeft. Ik heb eigenlijk geen idee gezien ik enkel dat bericht in de mailing lijst heb en die zegt toch echt "We have now disabled pushes altogether as well" :+.
offtopic:
Ik heb nu al 5 keer opnieuw het bericht gelezen, maar kan hem niet vinden. Ik weet niet of het mijn dyslexie is of wat anders waardoor ik er overheen lees, maar je zal hem ff aan moeten wijzen :').
edit:
Never mind, found it _O-. Ik ga de dyslexie er maar de schuld van geven :+.

[Reactie gewijzigd door Cambionn op 3 augustus 2026 12:58]

Ik wil toch even aangeven dat een Flatpak. appimage of Snap - ook vatbaar zijn voor precies dezelfde aanvallen. Dat zijn zeker betere alternatieven t.o.v. de AUR, maar 'heilig' ook niet.

Voor Flatpaks weet ik uit ervaring (als je package eenmaal is geaccepteerd), daarna vrijwel geen controles meer plaatsvinden. Het is beter geregeld (er is een algemene builder) en je moet toch wat hoepels heen, maar je kan echt wel doen wat je wilt. Ik weet dat, omdat ik ooit 3x iets had gepushed dat helemaal niet werkte, maar wel al werd verspreid aan gebruikers omdat het succesvol bouwt (had geen slechte bedoelingen, maar toch).

Snaps hebben hier ook last van gehad, en daar is nog een minder streng systeem dan Flatpak en misschien zelfs AUR. Appimages worden gemaakt door de vendor (dacht ik - corrigeer mij a.u.b.), maar ook die kunnen malware bevatten - en zijn mogelijk nog meer vatbaar, aangezien er geen centraal beheer systeem is (er bestaan oplossing voor).

Daarnaast heb je nog een heel ander probleem: deze bouwen allemaal vanaf de source. Als de bron is besmet, dan heb je precies hetzelfde probleem en wellicht nog groter. Bij de AUR iets dat specifiek iets dat een eindgebruiker moet inschakelen en installeren, een Flatpak werkt als een centrale appstore zoals Android/Apple Store.

Wat is dan de oplossing? Ik vrees een antimalware module, iets dat macOS bijvoorbeeld ook heeft. Misschien gaat er zelfs een AI-agent draaien die je moet gaan beschermen tegen malware die vecht tegen een AI-bot.. we gaan het zien.

[Reactie gewijzigd door HollowGamer op 31 juli 2026 21:58]

Arch Linux wordt vaak gebruikt door devs, dus op deze manier kun je een supply chain attack pogen op een ander stukje software binnen het 'Linux' ecosysteem. Denk hierbij aan de xz backdoor.
Wat is dan de oplossing? Ik vrees een antimalware module, iets dat macOS bijvoorbeeld ook heeft. Misschien gaat er zelfs een AI-agent draaien die je moet gaan beschermen tegen malware die vecht tegen een AI-bot.. we gaan het zien.
(Er is niet één oplossing.)

Anti-malware apps heb je zat voor Linux, maar dat verdient een fatsoenlijke discussie.

Zo min mogelijk software draaien buiten officiële repos kan ook al helpen.

Daarnaast kun je zaken in QubesOS draaien. Dan is het gescheiden dankzij VMs.

In ieder geval heeft OpenSnitch (layer-7 firewall) al diverse malware weten af te vangen. Ik gebruik dit nu ook al minstens tien jaar op Kali Linux.

Ook iets als SELinux kan helpen.

[Reactie gewijzigd door Jerie op 31 juli 2026 23:39]

Arch Linux wordt vaak gebruikt door devs, dus op deze manier kun je een supply chain attack pogen op een ander stukje software binnen het 'Linux' ecosysteem. Denk hierbij aan de xz backdoor.
Grappige is dat juist dat voorbeeld dan weer nooit op Arch heeft gewerkt omdat die dependend was op bepaalde "patches" die veel distros doen maar die Arch niet doet, en Arch de enige (of iig 1 van de weinige) was die niet tich versies terug hoefde om het eruit te patchen (wat een just-in-case patch was, gezien het dus al niet werkte).

Verder mee eens dat een anti-malware ook niet altijd de oplossing is overigens. Sterker nog, als je die weet te raken ben je meteen binnen met zeer veel access dus dat geeft ook weer een extra risico. En nee, ik ben niet per se tegen en mijn werklaptop draait ook zeer zware EPD software. Meer dar het een complexer verhaal is met verschillende kanten en overwegingen. Maar dat is idd een andere, zeer lange discussie.

Zelfde kun je overigens zeggen over de dingen die jij noemt. Het hangt uiteindelijk vooral af van wat je wil beveiligen, waar tegen, en hoe ver je daarin wil gaan. Goede tools slecht gebruiken is net zo problematisch, en te zware tools waar men vervolgens omheen gaat werken doordat de limitaties ze te veel tegenhouden of uit gebrek aan kennis verkeerd inzet ook.

[Reactie gewijzigd door Cambionn op 1 augustus 2026 13:50]

Is het niet zo dat flatpacks sandboxed draaien? Een PKGBUILD met installfile en rare instructies in post_install en/of post_upgrade worden bij het installeren uitgevoerd als root en kunnen je hele systeem overnemen.

Overigens is het niet alleen AUR... hoeveel 3rd party repositories zijn er wel niet voor Debian en Ubuntu? Iedereen voegt die maar lukraak toe.
De sandbox klinkt leuk, maar de meeste apps hebben 'host' toegang (filesystem=host) en gebruiken XWayland. Dat wilt zeggen dat ze overal wel bijkomen, op een aantal 'gevoelige' na. Een editor kan bijvoorbeeld nog altijd bij je videos, en een video speler bij je documenten. XWayland is vrijwel helemaal onveilig, naar mijn weten omzeilt dit het hele sandbox systeem van flatpak?

Het beste is dan ook die permissies na lopen, want Flatpaks staan standaard heel erg open, tenzij je iets als Secureblue gebruikt - die forceren echt dit. Al lever je wel in met gemak en performance. Je kunt het beter restricten met ~/Videos, ~/Documents, etc.

Je hebt wel gelijk dat een Flatpak niet die post hooks draait, dus bij de installatie kan vrijwel niets misgaan. Je kunt een app installeren als system, maar dan nog komt die niet bij je /root. Daarnaast heb je SDKs, die dan weer kunnen inhaken op een Flatpak.

Flatpak v2 gaat ook meer met portals werken en een veel beter systeem. Het is echt te hopen dat dit niet te lang meer duurt, anders hebben 'we' nog niets aan Flatpaks. Zo veilig als beweerd is het echt niet.

Een PPA is inderdaad nog onveiliger, het kan zelfs systeem packages pushen. Voor mij o.a. een reden heel voorzichtig te zijn met een PPA.

[Reactie gewijzigd door HollowGamer op 31 juli 2026 22:34]

Het rechtensysteem gebruikt bubblewrap, die kan met seccomp filters of AppArmor je hele applicatie beperken. Dat staat los van Xwayland. Wat met Xwayland wel kan is stiekem opnames maken van andere Xwayland applicaties.
Je hebt gelijk, en ik had dat wat duidelijker moeten uitleggen. :)

Het doet nog altijd die permissie checks, maar doordat het op X11 draait in feite, kan het van andere apps vrijwel alles zien en ik dacht ook dat wat je typt/doet overnemen. Als jij dus je wachtwoord ergens intypt of plakt, dan omzeil je dus nog altijd het permissie systeem (met een omweg), aangezien je dat kan afkijken. Of dat met bestanden die je plakt op je clipboard ook werkt weet ik niet zeker.

Ik weet niet of dit inmiddels iets beter is geworden (ook het onderscheid tussen Wayland apps en XWayland apps). Wat ik probeer is zoveel mogelijk apps te forceren Wayland te gebruiken (zoals Vscode, Firefox, ..) en XWayland apps niet te gebruiken (of enkel als ik ze vertrouw - maar dus met een risico).

Dat is een beetje wat ik bedoel met de sandbox. Het werkt, maar het is ook ultra gevoelig.
Ubuntu probeert dit wel te verbeteren voor snaps met app permissions. Ik kan het in Ubuntu 26.04 aanzetten in security center, maar het heeft nog de status experimental. Dus heb het daarom nog niet gebruikt...

Ik snap dat het op flathub of snapcraft bijna ondoenlijk is om elke update te reviewen, maar ik zou het niet gek vinden als een review plaatsvind bij een aanpassing van de sandbox configuratie.
Als ik het zo lees, wordt het een Windows Vista nachtmerrie met UAC lol.

Het klinkt heel goed op papier, maar Flatpak wilt juist standaard permissies aan hebben (beetje zoals Android) en voor gevoelige zaken een scherm. Dat werkt ook zonder apparmor, iets dat bij Ubuntu min of meer required is.

Is het ene beter dan het andere? Geen idee, Flatpak v2 heeft weer meer systemd deps.
Op Android of iOS krijg je ook wel regelmatig een schermpje te zien waarbij een app toegang vraagt to bepaalde functies of data op je telefoon. Dat idee heb ik, ik let er ook weer niet zo scherp op :).
De tijd van sec modellen op basis van compartimentalisering en wachtwoorden is voorbij.
We zitten midden in een transitie naar alles immuteable, ephemeral & code driven.
Daarna volgt pas de rest.
En als je locatie-permissies nodig hebt om Bluetooth te mogen doen, is het ook een 'het-zal-wel' als er een rare permissie staat.
Flatpaks zijn niet perfect dus ben wel benieuwd wat Flatpak v2 gaat brengen! Maar bij Flathub gaan alle nieuwe gepubliceerde Flatpaks wel door een review process heen eerst.

https://docs.flathub.org/blog/app-safety-layered-approach-source-to-user#submission--human-review

En daarna nog ook altijd nog door automatische testing waar ze voor een aantal dingen checken.

https://docs.flathub.org/blog/app-safety-layered-approach-source-to-user#automated-testing

Dat is ieder geval al heel wat meer dan wat je nu met PKGBUILDS hebt die op de AUR staan. Ik ben trouwens sinds kort ook van Arch Linux naar Fedora Silverblue gegaan en beheer mijn eigen image via het template wat Ublue aanbied waar mee dat een stuk makkelijker word. Ik heb tot nu toe alleen maar geverifieerde Flatpaks gebruikt en een paar Appimages die ik van de ontwikkelaar op Github of van hun website zelf vandaan heb.
De submissions zijn human reviews, maar daarna niet meer. Als jij maintainer bent van die (flathub-)repo, dan kan je vrijwel alles doen wat je wilt.

Het wordt wel sneller gespot, omdat inderdaad automatische testing wordt gedaan. Maar hoe diep die gaat weet ik niet. Er zit volgens mij geen check op of je bijvoorbeeld naar een vage externe host/partij gaat tijdens het bouw process?
Wat ik in het verleden wel is heb gedaan toen ik een tijd ook unverified Flatpaks gebruikte is voor die mij aanmelden bij de repo voor wijzigingen. Dan krijg je een mail wanneer er iets in de repo wijzigt en kan je als je het nodig vind even checken of the sources nog kloppen waar de Flatpak van gemaakt is, beetje net zoals met PKGBUILDS. Maar op dit moment omdat ik alleen verified Flatpaks gebruik doe ik dat niet, want ik gebruik nogal een lijst nu ik op mijn eigen beheerde Silverblue image gebruik.
Je moet natuurlijk ook wel een beetje zelf opletten wat een flatpak open zet.

Ik gebruik erg veel flatpak en geen van mijn containers hebben filesystem=host aan staan. Want dan kan je net zo goed de package uit je package manager halen.
XWayland omzeilt de beschermingen van Wayland ten opzichte van andere niet-Wayland-applicaties. Je kunt geen keystrokes injecteren in Firefox, maar wel in xterm die je ook onder XWayland draait (net als op X11).

Host filesystem is hier natuurlijk de grootste factor maar daar wordt je ook voor gewaarschuwd op de winkelpagina, al betwijfel ik dat veel mensen die melding lezen. Het is ook niet universeel: https://flathub.org/nl/apps/com.play0ad.zeroad heeft bijvoorbeeld alleen toegang tot eigen bestanden. Bij de AUR wordt je geacht bij iedere update voor ieder programma ieder buildscript door te pluizen, dat is toch een hele andere situatie dan het risico-overzicht op Flathub.
In mijn belevenis is de enige wat de sandboxes van Flatpak doen, is mij dwarsliggen.

Wil ik een bestand in een geFlatpakte applicatie openen? Moet ik het eerst naar een bepaalde directory kopieëren. En na de bewerking door die geFlatpakte applicatie weer terug kopiëren naar waar het hoort.

Onhandig.
Is het niet zo dat flatpacks sandboxed draaien?
Sort of, maar zoals anderen aangeven is ook dat niet zo waterdicht als het klinkt. Daarbij, genoeg mensen die de AUR gebruiken doen dit omdat ze juist dingen als "normaal" system package willen hebben. Ook dat heeft z'n voordelen namelijk. Uiteindelijk is het een kwestie van de pro's en cons overwegen welke optie het beste bij jouw casus past.

Beide kan een prima optie zijn, zolang je maar weet wat je doet en er goed mee om gaat.
Overigens is het niet alleen AUR... hoeveel 3rd party repositories zijn er wel niet voor Debian en Ubuntu? Iedereen voegt die maar lukraak toe.
Zeker. Er lijkt soms wat negatieve connotatie hierover naar Arch specifiek te liggen maar echt op elk systeem kan dit mis gaan. Echt Arch specifiek is het issue niet.
Doordat die pakketten eigen kopieën hebben van van alles kan malware (of oude bugs) daar heel lang in doorsudderen.
"Ja, het lek in (zeg) Python is gerepareerd, hoor, en we hebben de laatste updates geïnstalleerd!"
(Vergetend dat er tientallen implementaties van Python in allerlei snappakketten verstopt zitten, waar die bugs nog gewoon in kunnen zitten.)
Zulke ondoorzichtige pakketten zijn bommen, die op ieder moment af kunnen gaan.


De oplossing is duidelijk: alleen correct bewezen software toelaten. AI is die "woodpecker" waar Weinberg het al over had.

[Reactie gewijzigd door Madelijn op 1 augustus 2026 10:20]

Die aanvallen zijn anders. In dit geval gebruiken kwaadaardigen de optie om pakketten die al tijden niet zijn bijgewerkt te "adopteren" en dan updates te pushen. Daar heb je geen kwaadwillende ontwikkelaar of gehackt account voor nodig, dat is altijd gewoon een optie geweest op de AUR.

De impact van een Flatpak is ook beperkt vanwege de sandboxing als die aan staat (er staat een melding in de softwarewinkel als die uit staat, dan ben je net zo kwetsbaar). Bij snap moet je een waarschuwing negeren en een terminalcommando uitvoeren om iets zonder sandboxing te installeren.
Ik wil toch even aangeven dat een (...), AppImage of (...) ook vatbaar zijn voor precies dezelfde aanvallen.

(...)
Appimages worden gemaakt door de vendor (dacht ik - corrigeer mij a.u.b.), maar ook die kunnen malware bevatten - en zijn mogelijk nog meer vatbaar, aangezien er geen centraal beheer systeem is (er bestaan oplossing voor
Ik wil toch even op inhaken dat je niet de AppImages over de Flatpak/Snap/AUR-kam kan scheren.

Zoals je zelf al aangeeft: AppImages komen van de makers van de applicatie vandaan. Vergelijkbaar met Installers van Windows en .app/Universal binaries van MacOSX. Er zit geen packagemanagementsysteem tussen.
Tuurlijk kunnen die ook gehackt worden en daardoor malware verspreiden. Maar over het algemeen blijft de gedachte "van de vendor" = OK.

Bij Flatpak/Snap/AUR (en in het verlengde ervan F-Droid) is er een raar fenomeen aan de hand.
Daar kan Jan alleman dezelfde applicatie publiceren en het wordt maar voor betrouwbaar aangenomen.
Eigenlijk zou men naar FlatHub, SnapCraft, F-Droid en FOSSHub moeten kijken zoals men naar "freeware verzamelsites" zoals Major Geeks, SnapFiles, FileHippo en Download.com kijkt.

Komt het niet van een website/webpagina dat onder beheer staat van de maker? Dat is verdacht.
Maar dat laatste is het ook niet. Zo uit mijn hoofd waren er een aantal bekende tools die zo gehackt en malware verspreid hebben, zowel Windows/macOS apps waren dat.

Denk de enige is ondertekenen, en dat per release. Maar dat is vrijwel niet bij te houden.
Volgens mij gaat "package adoption" erom dat oude pakketten die niet meer onderhouden worden, overgenomen kunnen worden door een nieuwe "maintainer". Dat was ook het mechanisme dat hier misbruikt werd. Het klinkt mij dan ook niet alsof ze de hele AUR offline hebben gehaald.
edit:
@The Zep Man haalt het ook al aan, zie ik

[Reactie gewijzigd door psalden op 31 juli 2026 21:49]

Je kunt een 'package adopten' als die geen maintainer meer heeft. Vroeger was dat geniaal, want dan stond er wel iemand anders op en er was een meer algemene community. Het was ook allemaal wat kleiner, door CachyOS en andere, is de AUR ontzettend gegroeid in aantal.

Er zijn best veel vaste ontwikkelaars weg bij Arch Linux, en als je ouder wordt - ga je misschien toch kijken naar een Fedora of zelfs een Debian. Ik zit bijvoorbeeld nu op Fedora Atomic varianten, want ik wil geen gezeur meer met verschillende packages en ga je gewoon één of meerdere images terug bij issues.

Dus ik denk dat het een combinatie is van beide. Het is ook heel eenvoudig, bij de meeste distros moet je als ontwikkelaar door allemaal build systems.

[Reactie gewijzigd door HollowGamer op 31 juli 2026 22:07]

Ik raad aan om eerst in de Flatpak/Flathub packages te kijken voordat je naar de AUR uitwijkt. De AUR is geniaal maar ze moeten dit echt even uit vinden, anders is het niet echt veilig te gebruiken voor dingen serieuzer dan wat gamen.

Mochten flatpaks nieuw voor je zijn, denk er om dat er wel wat bij komt kijken met deze sandboxed applicaties - je merkt het bijvoorbeeld bij het selecteren van bestanden van het filesysteem of drag & drop.

Dat kan je beheren met de flathub applicatie "Flatseal" - alhoewel de beschrijvingen nogal technisch zijn af en toe. Gelukkig hebben we AI vriendjes die alles voor ons uitleggen tegenwoordig.
Voor nieuwe Linux gebruikers is de AUR juist heel erg fijn. Spotify, VSCode, fonts en heel veel andere populaire apps/libs staan daar, en niet in de core-repos.

Ik weet niet of CachyOS tegenwoordig Flatpaks standaard aanzet, maar de reden dat de AUR zo populair is/was, komt ook door die sandbox van Flatpak. Mensen snappen het concept niet, en ik vind persoonlijk dat portals echt nog veel meer werk nodig hebben (vergelijk maar met macOS).

Voor mij is dit juist de reden geweest om weg te gaan van Arch Linux. Ik wil een distro met SELinux (niet apparmor), Flatpaks (alles - geen uitzondering) en containers (distrobox of toolboxes). Arch Linux heeft nog altijd geen apparmor support (het doet niet super veel) en SELinux kun je al helemaal vergeten.

CachyOS heeft dat ook allemaal niet, en ik vind het echt schokkend als een noob van LTT in het bijzonder, gaat roepen dat hij die gaat gebruiken 'want die zit niet in de weg'. Het hoeft niet tot op de millimeter dicht allemaal, draai zelf ook CachyOS op de SteamDeck, maar ik volg daar wel hetzelfde principe. Ik vrees dus dat malware alleen maar gaat toenemen, kijk maar hoe die gasten van LTT op alles en nog wat klikken.
Voor nieuwe Linux gebruikers is de AUR juist heel erg fijn. Spotify, VSCode, fonts en heel veel andere populaire apps/libs staan daar, en niet in de core-repos.
Dat vind ik dus ook! Ik sloeg echt stijl achterover hoe vreselijk gebruiksvriendelijk de AUR juist is voor iemand die gewoon "wil gaan", zoals ik. Toch heb ik altijd mijn AUR packages beperkt tot een handjevol, zodat het wat behapbaarder is mocht er zo iets als dit zijn met malware.

Flatpaks zijn gewoon TE finicky (nog). Als "we" daar nog een slag kunnen maken, dat je permissies in kunt stellen op een manier dat ook een normaal mens begrijpt, zoals gebruikers dat in iOS bijvoorbeeld kunnen doen - dan is het een stuk meer mainstream.

CachyOS lijkt nu meer te richten op "Shelly" dat AppImages en Flatpaks wat meer natuurlijk lijkt te ondersteunen? Misschien dat eens in de gaten houden of dat de juiste richting op gaat. Tot nu toe vind ik het wel weer een heel matige UI.

Ik vind Bazzite ook te gek, dat lijkt me meer in het straatje van dingen wat je benoemd... ik moet alleen immutable/atomic beter begrijpen...

[Reactie gewijzigd door fedaykin op 31 juli 2026 22:43]

Met CachyOS wil je ook Flatpaks vermijden, aangezien die geen v3/v4/zen libraries hebben bij de app. Je wilt zoveel mogelijk snelheid, dus je kiest daardoor al veel sneller voor AUR.

CachyOS heeft zijn eigen repos, maar nog altijd val je vaak terug op de AUR.

Helemaal met je eens over die portals. Het werkt met Flatseal enzo, maar het is voor een gebruiker niet te snappen. Die moet gewoon zien 'Mag deze bij je Downloads map?', en niet allemaal vage dingen als xdg/x-downloads..

Bazzite is opzicht prima. Ik bouw tegenwoordig images zelf met ublue, het is een vrij cool en begrijpbaar systeem. Voor mij gevoel moeten de die hards echt nog hier aan wennen, maar ik ben juist blij dat alles afgescheiden van elkaar is.
Zelf zit ik ook op Bazzite, meestal is mijn volgorde van voorkeur:
  1. Flatpack
  2. Brew
  3. AppImage
  4. Podman ('variant' op Docker)
  5. Draaien in Distrobox (met distroshelf)
Eigenlijk kan ik wel alles draaien dat ik wil zo. Ik ben benieuwd waar jij tegen beperkingen aanloopt waardoor je toch je eigen image maakt. En dat vraag ik uit oprechte interesse, het lijkt mij namelijk ook interessant om te gaan doen maar ik mis nog een use case. Helaas is er (nog) geen 'Het grote [atomic linux/ublue] topic' op GoT voor zulke discussies.

*Ik wil binnenkort ook eens leren hoe ik zelf flatpacks maak van open source software, zodat hopelijk mijn AppImage en Distroshelf gebruik tot een minimum wordt beperkt. Distroshelf wordt dan vooral een trial/dev environment voor software die ik nog niet regulier gebruik.

[Reactie gewijzigd door tweakuwe op 1 augustus 2026 14:50]

Die is er een beetje: Hoe maak ik mijn eigen Linux distro?

Ik heb een aantal packages die ik niet als overlay wil hebben. Denk hierbij aan modules en fish-shell bijvoorbeeld met toebehoren. In de ublue images zit standaard geen brew, en dat is ook niet iets dat ik wil. Door het zelf te bouwen, zitten die echt in je image en mislukken die ook als het misgaat. :)

Vervolgens draai ik tools als claude in een toolbox of podman-container. Voor GUI apps, alles Flatpak. Sandboxing is voor mij niet perse de hoofdreden. Het voordeel is dat alles zou moeten werken, aangezien de libraries matchen met het project. Daarnaast gooi je heel eenvoudig de app + appdata snel weg. 'Vroeger' moest je dan door ~/.local en ~/.config gaan, al vinden sommige apps nog altijd dat nodig. :/

[Reactie gewijzigd door HollowGamer op 1 augustus 2026 17:37]

INSTALL GENTOO :+ ( Het is voor het eerst dat ik dit niet primair als grap schrijf )
Leuk om te lezen dat je ook je eigen ublue image bouwt :)
Is er een manier om te controleren of je hierdoor geraakt bent? Ik heb eergisteren nog packages vanaf de AUR geïnstalleerd, maar ik heb de PKGBUILD files zelf al weer verwijderd.
Ja in principe is dit redelijk eenvoudig: de PKGBUILD die je hebt gedownload, is dezelfde welke je kunt inzien als je onder aur.archlinux.org je pakket opzoekt. Als de PKGBUILD van een recent (als in recent geintroduceerd in de AUR) pakket is waar een aanvaller iets verdachts in heeft opgenomen, dan kun je in elk geval vaststellen dat er waarschijnlijk iets aan de hand is met je systeem.
Ik denk enkel je processen checken en je journal.

Heb je snapper? Anders kun je voor de zekerheid altijd een snapshot terug gaan.
Timeshift voor als je nog op ext4 zit ;)
Het is de derde aanval.

Na de eerste aanval was er een paar dagen later een tweede.

(Dat heb ik toen trouwens getipt naar Tweakers maar dat was genegeerd.)
... dat Arch wordt aangevallen, btw.
I see what you did there.
Er wordt altijd aangeraden om de PKGBUILD te controleren, je ziet waar de sourcecode vandaan wordt gehaald, maar of die code veilig is kan je niet zien.
Soms zijn er gezonde indicaties. Bijvoorbeeld: je ziet in een PKGBUILD diff dat alleen het versienummer is opgehoogd en dat de bronbestanden van een officiële locatie gehaald worden. Dat is vaak een goed teken. Als de originele bron gecompromitteerd is, dan heeft het niet enkel effect op AUR.

Dan nog blijft AUR een risico voor het ongetrainde oog en voor degenen die AUR helpers gebruiken met een "--noconfirm"-achtige parameter.

Het onderliggende probleem is dat iedereen (onder een pseudoniem) AUR packages die niet meer onderhouden worden eerst kan oormerken als orphaned wanneer de ontwikkelaar niet reageert. Daarna wordt een aanvraag om de ontwikkelaar van het package te worden automatisch goedgekeurd. Je krijgt dus ook problemen als een package wel onderhouden wordt maar de enige ontwikkelaar even een tijdje niet beschikbaar is (bijvoorbeeld op een lange vakantie).

[Reactie gewijzigd door The Zep Man op 31 juli 2026 21:27]

Dat "automatisch" is niet geheel waar. Als iemand 2 weken na het flaggen niet reageert kan je een verzoek naar de mailinglist sturen en kan een package maintainer het pakket in orphan status zetten.

pas als een pakket voor 180 dagen flagged is gaat een orphan request volledig automatisch.

Ik vind het een dom systeem overigens. Toen ik nog package maintainer was had ik >600 pakketjes in beheer. Onder andere GNOME en X.org en alles wat daarbij hoort. Hoe vaak ik wel niet flags kreeg voor development versies van GNOME... en dan kon je unflag doen maar de volgende dag stond ie er weer. Op een gegeven moment heb je wel wat beters te doen dan flags uitzetten.

Ik heb overigens ook wel zooi uit de repos verwijderd wat vervolgens in AUR gezet werd voor die ene gebruiker die nog zin had om libgnomeprintui te gebruiken bijvoorbeeld. Dan werd zo'n pakket door iemand overgenomen en compleet verbouwd zonder dat het iets toevoegde aan het eindresultaat. Puur voor de status "kijk mij eens hoeveel pakketjes ik heb".
Ik vind het een dom systeem overigens. Toen ik nog package maintainer was had ik >600 pakketjes in beheer.
(...)
Dan werd zo'n pakket door iemand overgenomen en compleet verbouwd zonder dat het iets toevoegde aan het eindresultaat. Puur voor de status "kijk mij eens hoeveel pakketjes ik heb".
Hier zit een stukje ironie in. ;)

Voor software die niet door Arch Linux geleverd wordt zie ik een nut van AUR. Als je echter veel oudere software moet gebruiken (zoals legacy GNOME en X.org spul) waarvoor veel pakketten vanuit AUR nodig zijn, dan denk ik dat Arch Linux niet de juiste distributie is om te draaien.

[Reactie gewijzigd door The Zep Man op 31 juli 2026 22:43]

Meestal gooide ik die boel gewoon zo uit de repos, maar collega's vonden dat het in AUR gedumpt moest worden.

Libs die upstream inmiddels in het archief staat en geen commits meer ontvangen, door geen enkel ander pakket nog nodig, weg ermee. Waarom zou je als gebruiker die oude onbeheerde meuk willen blijven gebruiken?
Toen ik nog Arch Linux draaide (5 jaar geleden), klikte ik op de GitHub link en schakelde daar (ook) updates in. Zo kon ik beide in de gaten houden.

Een 'noob' zie ik dit niet doen. Sterker nog, ik denk dat die verwacht dat iets veilig is - anders wordt het niet gepushed.
Het is de laatste tijd wel raak met die aanvallen valt me op. Zou dat door AI komen of omdat de AUR packages niet veilig zijn? Of omdat Linux meer gebruikers heeft dan ooit? Of omdat iedereen daar iets kan uploaden? Geen kritiek, alleen interesse.
Alle software heeft een bullseye op zijn rug. Met de populariteit groeit ook dat doelwit in omvang mee. Met AI heeft het allemaal vrij weinig te maken. Mijn bescheiden mening op dit vlak is dat je nooit met techniek gaat afvangen wat bij "personeelszaken" fout gaat. Als je het toestaat dat iedere jandoedel uiteindelijk dingen kan inbrengen in je repository, dan kun je erop wachten dat er figuren tussen komen te zitten met minder nobele intenties. Procesmatig moet je als project zorgen dat je daartegen bestand bent (niet makkelijk) of accepteren dat je geregeld dit soort ellende aan de hand hebt.
Ik draai al een hele tijd CachyOS en heb de AUR meteen disabled, ik doe niks geks op mn laptop dus met standaard packages en Flatpaks red ik me prima
Ik heb jarenlang Arch gebruikt, ben een jaar of 12 package maintainer geweest, maar heb nog nooit echt wat nuttigs uit AUR gehaald. Kwaliteit was vaak matig.

Als ik iets nieuws moest packagen wat nog niet in core of extra zat was het meestal gewoon een PKGBUILD kopieren en de variabelen aanpassen. Meeste software is 3 regels in build() en 2 in package(). Soms een patch erbij en soms een .install bestand. Als het wel ingewikkeld werd keek ik liever de specfile van Fedora af.

Om te kunnen reageren moet je ingelogd zijn