Where the AUR users at?
2d 4h ago by lemmy.world/u/cannedtuna in linuxmemes
Never trust an NPM library
Fuck node
... technical name for glory hole
OR
Your mom's a fuck node
bu-but so many libraries need funding!
Linux Users: haha those silly windows users, always searching the web for their software and getting viruses.
Linux Users: oh no I got malware by searching the AUR!
Don’t worry, I found a package on npm to help!
The AUR is still safer. One, it is at least minimally moderated. If a malicious package is detected, it can be reported and removed. Two, the installer is usually not just a black box executable. Three, most of the build and runtime dependencies are from the official Arch repos, which provides some protection against supply chain attacks. For Windows installers, you have to trust the distributor to bundle clean DLLs (for that matter, the same applies to AppImages).
But if it starts downloading anything from NPM... ^C and run.
The most unsafe factor of the AUR is aur helpers and their goal to dumb everything down and streamline the process as if the AUR where an official repo
Ye my reaction to this was basically uninstalling yay to force me to do it manually
I'm not entirely sure I agree, I think the issue is with default settings.
Like you could use both yay and paru to diff the PKGBUILD of the most recent updat and then read it, and then approve each. And I think that's pretty helpful. But you could also just blindly accept the update with the right config or flag and that is not a good practice.
Yeah, use and promote aurto instead. They require you to trust the maintainer and would remove the package from the local repo if the maintainer is changed
I'm not sure if loosing the maintainer is to only thing we should be going off of here, but I like the name.
Well, it is just like a distro maintainer account anyway. If the maintainer account is compromised then gg for the whole distro. That's what happens with other supply chain attacks as well and yes, I do think we need a way to fix that without compromising on ease of usability
We arnt talking about a distro maintainer, but an aur package maintainer, which can be anyone.
Yes, and that is no different than distro maintainer that maintains the infrastructure and package. Anyone can volunteer. That's how xz is compromised. The point is that aurto trust models mimic those of other package managers. Trusting the authors implicitly trust the code. The only other special things from distro maintainer is their PGP signatures are required to perform release on the main repo. This is better because as I stated earlier, reviewing PKGBUILDS would encourage people to just skip it. Not everyone has the time for that. But when a maintainer changes? Aurto removes the package for you to perform that first trust again on the new maintainer. This is no different than if you update the arch keyring just more manual
No, an aur maintainer is not the same a distro maintainer.
But I do agree it would be good to atleast stop and evaluate when the maintainer changes or a package looses the maintainer at a minimum.
I know where you're coming from when you say they are different. But I disagree on that because at the end of the day you're still trusting other people would not act maliciously or get their account compromised. The selection process doesn't make it any more special as demonstrated by xz in my example.
Anyone can be an AUR submitter and maintainer. Act in good faith and never become an Arch maintainer. Someone can be an Arch maintainer and be good for a few years then something happened and their account got hacked or bad blood made them act rashly.
That's precisely what I mean when I equate AUR maintainer to the distro maintainer. To the package management system, they are both trusted. Not in the sense of how special they are or how strongly you can trust one but not the other.
But Windows has a flourishing antimalware ecosystem. That's missing in Linux imo
appimages are kinda like portable app versions.
By misusing the AUR and ignoring every warning telling you to read and understand the pkgbuild or don't do it.
AUR naur! for all my Australians out there.
The more popular Linux becomes, the less true this will be.
Avoid success at all costs - Simon Peyton Jones
Tbf most major attacks we saw recently are cross-platform thanks to npm. AUR has always been a security risk.
Wasn't that long ago when I was downvoted to oblivion for saying that. Glad to see the community is maturing.
btw, I use malware
Microslop is nervous now that Linux is popular enough to attack.
Linux has always been the bigger target. Even microslop uses linux for its severs.
I'm gonna assume that their servers are not installing stuff from AUR though
I would hope so too
They also have been developing a Linux distribution for 6 years. https://en.wikipedia.org/wiki/Azure_Linux
I don't use Arch, BTW. So the biggest NPM threat vector on my machine is still VSCode.
I was anti GUI for years. Having learnt to program on a tiny green and black 40x24 CRT on my old MSX back in the 80s. I remember being made fun of by fellow students and co workers alike for doing almost everything in the terminal. This included huge projects with complex file trees and lots of files.
But as time went on, I started to appreciate the GUI more and more. And these days I'm all for using a GUI for a lot of things.
Especially in IDEs that can do a lot of things with short keyboard shortcuts. I now have multiple monitors, including a large 32" primary. I always have stacks upon stacks of windows open and manage them efficiently. There's always at least a couple of terminals hanging out and of course most IDEs also have terminal windows baked in. But all of the extra visual tools help me out a lot.
Almost the exact opposite for me. Used to hog GUIs and hated keyboard shortcuts with a passion, but then I came across Niri, fell in love with the idea, and the whole scrolling window manager thing made my productivity explode. I can’t use traditional desktop environments anymore. Tried to go back and literally can’t.
Tmux wasn’t that far behind.
and the whole scrolling window manager thing...tmux wasn't that far behnd
I remember one time reflecting on how many layers I have at which one can expand workspace.
-
Linux virtual terminals. By default, Debian runs 7 login sessions on seven virtual terminals and sticks the GUI (Wayland/Xorg) on the eighth. So Control-Alt-F1 through Control-Alt-F7 will get me a Linux terminal. I can stick more programs on more virtual terminals with
openvt. That's the first layer. -
Okay, so on virtual terminal 8, I've got Wayland running. On that, I'm running Sway. That has an infinite number of workspaces that can be created. Currently, I only have bindings set up for 10 (and I use nonstandard bindings for them, Super-q N to switch to the Nth workspace) because I didn't find myself actually using named workspaces. This is the second layer.
-
Within a workspace, I can have Wayland windows. Say I can have two or three windows reasonably visible. This can be expanded whenever opening a window; for example, Super-t to open a new virtual terminal emulator window. This is the third layer.
-
One of the most common windows I use is a virtual terminal emulator,
foot. That can run a program. I typically have it running tmux, which can have its own list of concurrently-running terminal programs (I use Control-O as the tmux meta key). This is the fourth layer. -
I often use emacs. Emacs has multiple "frames"; one can "clone" the current frame with
C-x 5 c. When run in a terminal, this basically acts like another tmux-like layer where one shows one frame at a time. This is the fifth layer. -
Inside an emacs frame, one can have multiple emacs windows (analogous to what is typically called "panes" in other software) showing various things at the same time. One can open a new window with
C-x 2orC-x 3, cycle withC-x o. This is the sixth layer. -
Emacs has a list of buffers, any one of which can be shown in a given emacs window. A "buffer" is vaguely analogous to "an open file" in some other programs, but could also be showing a terminal emulator or similar. One can switch with
C-x b. This is the seventh layer. -
Say I'm running a terminal emulator in one running
bash(M-x term RET RET).bashhas its own job control; one can suspend a running program and bring bash to the fore with Control-Z, list running jobs withjobs, then resume a suspended job in the background with$ bg %1to background the first or bring a job to the foreground with$ fg %1. This isn't quite the same thing as the other layers, since the screen state isn't maintained for separate programs and restored, but it can reasonably allow one to run simultaneous things and follow each. This is the eighth layer.
Noping the heck outta that. All I want is better top-level organisation, you just described what I’d call an anti-pattern in my book.
I wouldn’t nest things that deep through so many different tools/framework/layers that can’t talk to one another. That’s just asking for trouble. You’d waste one of two things: time searching or focus for memorising and recall, you lose something either way. And in the case of the latter you’re bound to forget and start wasting time to search over time anyway.
I'm a longtime vim user and I use nvim+lazyvim for all my personal stuff these days, but I have to use enterprise managed VS or VSCode for work.
I'm trying out Zed
Inverted security by obscurity
Obscurity by security?
Sescurity by Obcurity
Obituary by Sorcery
I avoid orphaned unmaintained packages and I wait a few days before I type yay
You're no fun
Is there a flag to prevent orphaned packages from installing?
Good question, I guess I might be using the wrong word when i say "orphan" because I see the arch wiki uses that term differently
Orphans are packages that were installed as a dependency and are no longer required by any package.
You can remove these manually or if using an aur helper like yay there are flags/settings you can use to delete them after the desired package was installed.
However what I was talking about aur packages that are unmaintained or do not have a maintainer anymore.
I'm researching more at the moment.
shit, I had 150 orphaned packages
pacman -Qdtq | pacman -Rns -
I made an alias for this, but IMO this cleanup should be automatic. The user didn't install it themselves after all.
This can be prevented by uninstalling with -Rs
Just removing them without user intervention could cause unexpected behavior.
I don't trust that everything that outputs from pacman -Qdtq should be deleted. Like I want to keep vlc.
I think if you do pacman -S vlc it won't be orphan anymore though. I removed everything, if I miss something I'll install it again.
A simple install kept it orphaned. Instead I needed to run sudo pacman -D --asexplicit vlc
Waiting for updating doesn’t make any difference. The packages could be infected at any point.
The packages could be infected at any point.
I guess the same could be said for literally any open source or freely distributed project.
The difference is that this was a supply chain attack and, to my knowledge, required the package to be listed as orphaned unmaintained first so that the PKGBUILD could be modified to install malicious NPM packages.
The community caught it quickly because it is possible to read both the PKGBUILD and the output of the update and, I think, it is fully resolved as of now.
Basically, if one were to delete or replace orphaned packages then they wouldn't have been infected.
It is also possible to add a CVE scanner for AUR packages if reading the PKGBUILD is too much, I'm looking into how to do that now.
All this is to say that you should check if you had an infected package but I personally don't think using the aur is more risky than using a flatpak.
Waiting for updating doesn’t make any difference.
Are linux users allowed to juat lie like that? I thought if you do that you need to use Windows.
C'mon, man, at least pour one out for the homies who waited to update and landed in the period where it was live and undisclosed.
What?
They also wait until they get off the rollercoaster and back on solid ground before yelling yay!
I never had any issues on TempleOS.
Zero remote exploits since it was released. That's what divinely-inspired coding looks like, everyone.
Out of curiosity, is that actually true? Surely our lord and saviour must have made a tiny slip-up
Edit: Apparently TempleOS doesn't have networking
It is networked >to G̷̗̙͚̥͓̼̠̩͙̀̃̎̌ǫ̷̢͈̭̪̮̝͚̟̹̭̤͇͕̪̍̅̈́͊̌̀̐͌̽d̷̡̮͕͉̥̂̽̔̾̓̋̚͘͠!<
Better than OpenBSD
My OS is a temple. 🧘
Same on Secureblue.
And you believe that makes you safe?
Shit like this is a blemish on the Linux community.
Also, an ad blocker.
ClamAV users, how's it going?
Did clamav work with AUR affected packages? Sorry if the question is idiotic, cause im ignorant when it comes to security
To be honest I'm not really sure, my comment was meant as a question to potential clamav users, I'm not really one of them.
I am really curious about this. If someone had ClamAV and updated any of these packages from the AUR during the attack, would ClamAV have "solved" that problem? I would love to know the effectiveness of that.
AFAIK ClamAV is mostly for looking for windows targeted malware so I doubt it
To be honest I'm not really sure, my comment was meant as a question to potential clamav users, I'm wondering the same thing as you.
clamav gang!
I was on arch as a vestige from my school days, having never quite found the time to switch to something more stable. When I saw the news over the weekend, I checked and found 1 would-be-infected package on my machine that was thankfully months out of date. I'm well past the point of wanting to examine PKGBUILDs every time (hence the out of date package). But, instead of just removing AUR packages and sticking to arch repos, I decided to sweep up the technical debt by wiping and installing Fedora. I'm liking it so far, minus the absolute pain in the ass that is Nvidia on Linux. Fuck academics and their insistence on writing everything targeting CUDA; otherwise, I'd have saved a good bit of money a few years ago with a much more compatible AMD card.
Have you looked into drop-in (ZLUDA) or recompile (SCALE, chipStar) things? Though they may not have been helpful with the years gone by (and may each have their own pros/cons).
I'm still using a 1050Ti (and legacy driver shifting to AUR did block me from updating), value doesn't seem great and not going to buy something used from eBay. So that still complicates things for me.
Distro-wise I probably want something slower than Arch but not sure about point releases. And I am hoping for something that does updates in a way more friendly to slower internet (giving less update friction), but I suspect it doesn't exist. Some things (OpenSUSE, NixOS) seem like they might be closer to I want but I have hangups about them (Patterns on SUSE and lack of videos for Slowroll, NixOS having multiple solutions for dynamically linked executables especially if I decide to stop using Steam directly).
The most frictionless distro to install nvidia drivers is Aurora. As you get ready to download the ISO, it will provide a couple of drop down menus to select your gpu. Intel/AMD is one and the other lists nvidia gpu's by card to add the correct driver to the ISO. You should be able to install the ISO and boot into your shiny new Plasma desktop with your nvidia gpu working just fine.
And you get the atomic goodness of Fedora Kinonite.
Isnt it just a single line command to get nvidia working?
You add the rpmfusion repo and install a few nvidia packages from there. Kernel modules are then built for the driver. If secure boot is used, they need to be signed too. Sometimes the grub entry isnt updated and doesnt load nvidia drivers. Sometimes you boot into a black screen, sometimes Wayland throws a hissy fit. Hardware accelerated video decoding needs more packages, in browsers it may need extra configuration..
The components are all there and they work, but sometimes the stars don't align and you just curse a little and wonder why you didn't just buy AMD because that, just works.
Yep, checklist of basically everything I went through over the weekend. Sorted now, thankfully
It's a couple commands and laid out cookbook style. Fedora has a very good document page on installing nVidia drivers. And the installation is generally very smooth.
The biggest hang up for first time users is understanding that you need to wait for everything to build before doing sudo systemctl reboot. How long do you need to wait? No one really knows. There is no progress bar or any other notification that the building is done successfully. You just wait and then take a leap of faith into that dark abyss and hope for the best.
Typically, it's recommended to wait “at least 5 minutes”. Maybe more. I always waited around 10 minutes, (or one cup of tea) to be sure. But some users reported needing to wait was much as 20 minutes for everything to build. YMMV
Regarding the wait time, maybe I just got lucky, but just waited for my CPU usage to come back down and spammed modinfo -F version nvidia or some such until it stopped erroring. My actual hang-up was getting simpledrm working and then secure boot.
In the simplest case, absolutely. I ran into black screens and wayland issues due to a combination of needing to enable simpledrm in the command line and working with secure boot. Not too much extra once you figure it out, though.
Arch users just randomly dropping "I use Arch btw" everywhere, it was only a matter of time.
I use Arch btw
With the old package managers safety was simple...trust the developers, user their packages. 10000 downloads? Easy! 1 download.... 🤔 Maybe skip for now.
Now with executables like mac and Windows it's easier to sneak something in. You still rely on trust. But now you've got AI in the game mudding the waters.
So what are good antivirus options for Linux? is it still pretty much just ClamAV?
Our company uses eset https://www.eset.com/us/home/antivirus/
But afaik it costs money to really work.
But your brain should be the best antivirus you have.
But your brain should be the best antivirus you have.
Is there an AUR package for it? seems not in the official repo
But your brain should be the best antivirus you have.
It's useful to use brain, but any security layer has holes which is why it's good to have several layers. Some attacks might be way beyond user's understanding or come from trusted sources.
But your brain should be the best antivirus you have.
True of virtually every OS.
But "only stupid people get viruses" is exactly the kind of trap that catches folks.
I have eset home but now I've gone completely linux, and they don't do it for home - only business
Which sucks, as I have a year left on my subscription I can no longer use :/
one thread I found from 2 years ago where someone asked for the same thing, a lot of the replies are just "you don't need antivirus on Linux" lmao
There is no malware on Linux and there is no war in Ba Sing Se
a lot of the replies are just "you don't need antivirus on Linux"
Which is completely true when using distros like Debian, Fedora, RHEL, OpenSuse, etc.
Arch (and its derivatives) are designed to be on the bleeding edge with ALL the paper cuts that come with it. It is absolutely not focused on stability or security. If you want those things then stick to Debian or Fedora Silverblue.
And the second you introduce npm to your system you can throw any semblance of security out the window, regardless of what your operating system is, and no antivirus is going to save you.
That being said, the fundamental security models between Linux and Windows are very different. And on Linux the overall impact will likely be far less damaging (technologically, not financially) than on Windows. Windows "security" is just a corporate marketing campaign.
If you use snap, or flatpaks, or npm, or anything like that you run the same risks.
npm, yes. Snap and flatpak? No. I'm not saying it's impossible to get malware. The difference is that snapd and flatpak have various levels of process isolation that largely mitigates any potential issues.
The argument isn't "Linux doesn't have malware", the argument is "you don't need to run antivirus on Linux". Those are two very different things.
Not even the best antivirus will protect you completely, at that point you need good computer hygiene.
Eh. Flatpak has the option for process isolation, but it kinda works similarly to how android apps have default permissions set and the packager can just go "nah, this gets FULL permissions" and unless you go look and change it yourself, the program isn't restricted at all. I don't use ubuntu/snapd so can't speak to that.
There are more protections on flathub than the AUR for sure - the AUR is closer to just downloading random shit off the internet than a true repository. That said, it's crazy to assign the vulnerabilities of the AUR to Arch as a whole... The Arch repos proper (and even Chaotic AUR) didn't have problems during any of this.
It was certainly a weekend.
Yeah I'm pretty glad that I've been behind in upgrading my aur packages recently.
I learnt a lesson yeah. It looks like I got away, there's no rootkit, I found nothing weird running, I don't have npm Installed, and up until now it doesn't seem like the packages I had installed were compromised. But I had way more AUR packages installed than I was aware of. And I was just updating them without really caring about the pkgbuild, I have better things to do. Multiple packages were outdated crap that shouldn't have been there anymore.
I was careless and took too much risk. I reduced the Installed AUR packages to a minimum, and from now on I will verify the PKGBUILDs on every update. Maybe Arch isn't really what I need. I'm on the LTS kernel and I no longer really use the AUR. But switching will be a huge hassle and this setup will work well from here on out, so I'll stick to it for now
I've been using Bazzite for a couple of years now and it's great. Almost boring how stable it is.
And I access the AUR with an Arch distrobox if I need to
errr... just FYI, if you have AUR packages through distrobox, you are basically just as vulnerable as someone running vanilla arch. You checked if you have anything form the AUR on the nearly 2k (last I checked) package list?
Everyone knows if you use Kali you're immune to malware
I am at "no fucking yays and the bunch, check the package create/update dates, read PKGBUILD, only update when necessary". Has served me well so far
Security through insecurity
Though, Linux being open source helps a lot
Doesn't work like this.
Me!!!!
But I'm actually safe: Last month I fried half of my BTRFS array, and decided that instead of recovering the system, I'd rather copy over the relevant data and reinstall Arch from scratch. In doing so, I've shed the majority of AUR packages that my old system had. Of the handful of AUR packages on my new system, none were attacked.
Hi there 👋
Don't have installed much from the AUR though.
My eyes, I look at AUR packages before building them, as any real arch user does. AFAIK, antivirus programs would do the same to compiled binaries, looking for suspicious things and blocking if it finds something.
Anyone catch that hilarious LLM exchange on aur-general mailing list over the weekend?
E: found it
Well that's fun. Odd someone named Campbell asking was for a tomato soup recipe, you'd think that would just be built into their bloodline or something.
While I'm glad no JS package managers were hurt to make the soup, I do wish the recipe didn't waste so much water.
Just keep sending requests and use as many tokens as possible. My wife spent 30 minutes on the phone with a bot the other day, just getting it to dump huge sets of instructions to waste tokens.
Custom OS that no one else has access to. It might be full of exploits and bugs, but only you would know that. 😉
The unsandboxed package model was only ever safe in its original conception - with organizationally trusted and cryptographically enforced maintainer model. Remove the maintainer/developer trust requirement and you need a sandbox in order to prevent malware having root access on your system. Tis why mobile apps were sandboxed on Android and iOS from the get go.
Use the AUR, have an antivirus, no infected packages. However I was thinking of switching to https://chimera-linux.org/before the infected packages went out.
So... rkhunter?
Never use things like yay, just read the PKGBUILD and run makepkg. AUR wasn't meant to be automated. But it's better to use Flatpak, because it provides sandboxing (not for every app, but it can be reviewed before installation).
Using aur helpers is fine if they make it easy to read the pkgbuild, which paru does. It's too annoying to check for PKGBUILD and upstream/vcs updates for each package individually.
Ideally the aur helper would point out when 1) a package changed maintainers since your last install, 2) a package's PKGBUILD itself changed (not just the upstream/vcs source), 3) the PKGBUILD is less than 24h old or so. And for #2, it should also show you the changes similar to what you see on the AUR site's "view changes" page. I'm not aware of any aur helper that does these things, but hopefully recent events prompt a change.
ive been looking for an antivirus since i want to be able to download random stuff from the internet without having to review it
Clamav is pretty good if all you're wanting to do is scan the files you've downloaded so that you're not potentially re-transmitting viruses.
Outside of that, maybe consider using SELinux for security, or possibly if you're going to be doing risky downloads, do it on a virtual machine, on a virtual network.
I'm trying Clamav but its giving me (at least what i think is) a bunch of false positives. I'll look into SElinux.
Containerize or Virtualize whatever you plan to run, keep it volatile, otherwise you’ll have a host operating system riddled with unnecessary data.