Nearly 2000 packages affected now.
I’m starting to become sceptical of pacakge managers as a concept.
Why be sceptical of package managers because of the AUR. The AUR has nothing to do with package managers, it’s just a place people upload there install scripts for software outside the package repository
My problem is that we’ve normalised pulling massive amounts of random stuff from the internet without knowing what all of it does. Package managers make this effortless. For example NPM gets pwned seemingly every month. Also the whole XZ Utils fiasco from a copule of years ago. This is not normal
The AUR is explicitly covered in warnings telling you to vet everything yourself and that you could easily get pwned. Admittedly the process for taking over packages is too lax. The official linux repos are extremely good in general because they are subject to code review and more stringent requirements. Debian is moving to requiring signed packages which is good.
Software library management is different, and pointing to JS as an example of terrible computing practices is well, duh. JS is horrible and used by lowest common denominator people pushing slop out to make the web work worse. But library package managers are solving a different problem, not “how do we make computing safe and easy” which is the OS ones, but rather “how do we make development fast and avoid dependency conflicts”. The names are overlaps but the purpose is separate.
Shitty devs will get just as owned and own others by copying random unsafe code anyway, don’t use software written by shitty devs
The AUR is explicitly covered in warnings telling you to vet everything yourself and that you could easily get pwned.
Approximately 0 people saw those warnings. Ever. They all use some frontent like
yaywhich will happily install whatever malware you ask it toSoftware library management is different, and pointing to JS as an example of terrible computing practices is well, duh. JS is horrible and used by lowest common denominator people pushing slop out to make the web work worse. But library package managers are solving a different problem, not “how do we make computing safe and easy” which is the OS ones, but rather “how do we make development fast and avoid dependency conflicts”. The names are overlaps but the purpose is separate.
I don’t see how they are conceptually different. Sure, one of them has better quality control but we still get backdoors sneaking through into popular distros. OS package managers also have an effect on development. Devs rely on them to resolve a massive net of dependencies they create when the goal should be to reduce the number of dependencies
Shitty devs will get just as owned and own others by copying random unsafe code anyway, don’t use software written by shitty devs
What if the software was written by a great dev deliberately to own you? What if this dev was hired specifically to place a malicious line of code into do_some_basic_stuff.so library that everyone is using for some reason?
I don’t see how they are conceptually different.
With a Linux distro package manager there is usually a single version of a dependency and the maintainers try to keep that secure.
With programming package managers each project has it’s own decency tree. With npm there can even be multiple versions of the same decency in the tree.
Approximately 0 people saw those warnings.
Everyone knows the warnings, nobody does the reviewing. It’s a shit approach to community safety.
Yay is itself an unofficial piece of software with terrible security defaults such as not showing diffs by default. To install yay you go outside the official repositories, it is no more trustworthy than going to enthusiastsite.com and downloading some makewindowsawesome.exe
The AUR is still a better solution than everyone (mis)managing their own systems and never updating anything but it is not vetted, it’s in the bloody name what it is.
The rest is just social problems, if you’re not fit to audit code and have to rely on trusting maintainers why would you expect removing them would make it better. Look at windows for an indication of the ludicrous mess of out of date and vulnerable software or ransomeware etc that will happen.
There is a substantial difference between distribution package repositories and systems like NPM. NPM just pulls shit from random third-party git repositories. NPM gets pwned every month because the weakest link in the chain is some javascript developer, and the chain has tens of thousands of links. On NPM (and other similar programming language package managers) if the upstream developer pushes a malicious update, you’re already fucked. Could be a malicious developer, or it could be one of the credential-stealing ShitHub worms we’ve see go around.
Distribution package repositories are maintained and hosted by a third party (the distribution). If the upstream developer pushes a malicious update, nothing happens. If it is very well disguised, it could potentially slip into an unstable or testing branch, but there is also a time delay before things make their way from unstable to testing to stable, so there is a very high likelyhood the problem will be discovered before it hits the average person, assuming the maintainers don’t spot it immediately. The xz-utils attack was discovered and mitigated before it could be exploited as a result of this due diligence - though it certainly was a wake-up call.
Another part of the problem with “convenient” PLPMs is that it allows developers to choose whatever version of a dependency they want, so on a good day you only end up with 10 different versions of each installed. It is all about expedience. A lot of more conventional software releases vendor their own dependencies in as well. Distribution package managers go through great lengths to un-bundle these dependencies, such that everything included in the repository is depending on the one version of e.g. librsvg they ship, rather than every rust package pulling in whatever random versions of the 300 crates they happen to have listed in their cargo.lock. This substantially lowers the attack surface and constrains the amount of places malicious code can be hidden or un-patched vulnerabilities can linger indefinitely.
Distribution package repositories aren’t impervious, but they are substantially more secure than what’s going on when you put thousands of random upstream developers in the drivers seat.
NPM just pulls shit from random third-party git repositories.
Nah, people upload packages to npm. Some of the attacks actually relied on attackers uploading different code to npm than to the linked git repos.
My problem is that we’ve normalised pulling massive amounts of random stuff from the internet without knowing what all of it does.
Windows already normalized this over 20 years ago, by lacking any alternative. Nowadays there’s the Microslop store of course.
The alternative is the classic .exe fiasco that exists on Windows, with manual updating off sketchy sites.
the alternative is flathub
just kill internet access with flatseal to any apps that dont need it, done
Flatpak next is going to have even more fine grained network sandboxing (per-app DNS, VPN portal, apps can’t talk to each other in the same network).
But then we have to deal with permissions?!?! And the bloat! Oh god, the bloat!
price to pay to not have some 1337t dprk haxor in your computer
Every developer targeting Windows learning that having a self-update mechanism in your app is required because A: users don’t update when prompted and B: getting onto the Microsoft Store is a PITA.
Honestly most software shouldn’t require regular updates to begin with.
How else do you handle security vulnerabilities and bugs?
Just make better software to start with. Adding networking and software deployment to everything is a significant attack surface.
Updating software doesnt require networking or software deployment.
I haven’t dealt with package management on Windows through exes because that sounds like a nightmare.
If you look at the Python PEP history, there’s like 10 just for Windows installer bullshit and like every other month there’s some IT guy coming in and screaming about how they want the installer to be a specific way which is usually met with “if you want that you should do that then” since literally no one wants to deal with the installer since it currently functions and 90% of people are just using venv now anyways.
The AUR has tens of thousands of software build scripts (though in all fairness a lot of them are just downloading a binary from the Internet). This normally isn’t an issue if you treat Arch as DIY and do your due diligence but folk wisdom has people picking things like “CachyOS” for that peak gaming
performance who stumble haphazardly onto the AUR since the Arch base repositories of vetted software doesn’t cover everything.This was bound to happen at some point since it’s not 2002 anymore and the Internet is now an anarcho capitalist hell.
PyPi kinda has this issue too. The typo squatting epidemic has been discussed a few times.
I haven’t had many issues with PyPi, but any package manager is just running someone else’s code on your computer. You really should be reading the code, checking the sources, and validating the binaries with any officially supplied checksums.
The scariest situation is when someone has a dev dependency, that package is squatted or compromised, and an unpinned supply chain attack is carried out like what happens with NPM ever other day.
You can even see the discussions in that thread about the risk of a squatted package vendoring the real package or just pulling it in as a dependency during install, and sitting in the middle stealing whatever passes through.
I mean regular Linux package managers are better than the AUR, which is sort of a worst case.
I’ll use Debian as an example: New maintainers need their identity verified, they usually get a sponsor looking over their shoulder while they’re still learning, and they get quizzed on their ability. Maybe, after jumping through these hoops, they’ll be able to take over an orphaned package or two, or create a new package, which then takes weeks to propagate from “unstable” to “testing”, which then takes many months to freeze into “stable”, which is when most people would finally be able to install it via apt.
Meanwhile in AUR-land: Random person can just take over an orphaned package (or 1500 orphaned packages) via a fully automated process, and minutes later everybody gets to install that.
I always review the
PKGBUILDfile before building something from the AUR. I just make sure the source URL looks sane. What else should I be looking out for?Specific git revision is a risk because github will give you commits from forks.
Just tracking branches is kinda normal on AUR but is also not ideal since it exposes you to upstream getting screwed more directly.
Honestly my biggest disappointment with archlinux is that they haven’t written up something about the attack vectors that were actually used. Seems really important when you are betting on individual responsibility so hard. It’s also the norm to write an incident report after a fuckup even 0.1% of that size.
I just do
git clone "https://aur.archlinux.org/$AUR.git". Is that bad?I’m talking about the srcs used in the PKGBUILDs
What it does/commands it runs (e.g. in the
package()and such functions, the.installfiles too). If they pull in external scripts, especially from the internet. What said scripts do.
ⓘ This user is suspected of being a cat. Please report any suspicious behavior.
Which aur helper are you using? I’ve been using
yayfor years, but now I’m thinking it makes it too easy to just mash Y and skip all diffs etc when updating. I’d like one that forces you to check the pkgbuild before installing something…I wrote my own AUR helper
It’s more likely than you think!
no such problems with debian
flathub stays winning
I for one love having to rely on dozens or hundreds of independent developers for security updates, unmaintained notifications, and code audit.
So much better than subscribing to one mailing list and running one regular update operation that removed deprecated software.
Flathub is not as spartan as you think it is, but it certainly isn’t perfect. App developers still have to submit their software to moderators who have written guidelines to adhere to and there is a verification and trust system built in place.
Also all app developers have to stay reasonably up-to-date to shared flatpak runtimes that are controlled by the flathub maintainers and receive security updates.
I think both OS package managers and flatpak can co-exist, especially considering how flatpak was the staging ground for the new portals system and a permissions model akin to what android has had for years.
afaik you can support flatpak while not being on flathub, there are flatpak files
Until someone figures out how to break out of the sandbox
So for most users, avoiding the AUR pretty much sidesteps this, right?
Maybe this is the push I need to try out Gentoo
As far as I can tell this only affects AUR(which you have to go out of your way to access and you are encouraged to review all the build scripts, although in practice I suspect many people are complacent or not knowledgeable enough), not the official repos. I am guessing the official repos for gentoo and arch have similar security, but if you go and get unnoficial/user ebuilds for gentoo you likely run into many of the same situations (although I don’t really know much about the gentoo ecosystem).
It is also worth pointing out Arch probably has a much larger target on its back since it is much more popular and there are many distro’s based off of it(which tends to attract the less knowledgeable users, who are primed targets for just randomly getting AUR without thinking)
Edit: For gentoo, it looks like GURU is more secure and has trusted users who review, but in practice I don’t know how well they do review or if they have had problems of people trying to submit malicious scripts. Also, it looks like GURU is considered more “official” than AUR so they are not really direct comparisons but I suspect they play similar roles in the community.
I’m not super familiar with Portage but is it inherently safer than other linux package managers? How sure are you that all the code you’re compiling was not written by Mossad?
How sure are you that all the code you’re compiling was not written by Mossad?
Code is inherently untrustworthy. Even if you read every line of source code, can you be ceirtain that the compiler didnt inject some malware into the program? (or if you compiled the compiler, how can you be ceirtain that the bootstrapping compiler didnt embed any malicious code into that one?)
Computing requires trust. Computers are too large and complex to understand, ultimately you have to have a source or trust somewhere that you rely on to make you not owned and spend your own attention on other attack surfaces.
Computing is inherently insecure and risky, you must have a risk model and implement appropriate mitigations such as offline backups, non email 2fa, sandboxing and so on as appropriate to your situation.
I wish it were not so but it’s not even a capitalism thing, people have been fucking people’s shit up out of curiosity, greed, anger, or accident since forever.
I agree but I think there are a lot of ways to make computers safers. Enabling sandboxing by default, coming up with a more robust permissions system allowing programs to only access specific parts of the hardware and of the file system (Android already has this). But most importantly - making software that is small, simple and understandable to humans
The linux security model is outdated yes, nothing to do with package managers. I recommend using SElinux for finer management.
Software is how it is because people don’t want software that follows the unix philosophy. They want bloated pieces of crap that do everything, they don’t want to compose multiple tools or not have stuff try to guess what you mean to do. They want autoconfiguration and highly customised PCs.
You can set up your own system to be a lovely island of sanity and never install a browser or officer suite (I have walked this path and it’s very relaxing) but 99.999999999% of people are vehmently against this and also completely disinterested in their system. So here we are.
Software is how it is because people don’t want software that follows the unix philosophy.
Everything is a file means that every program needs a parser. Means that every program will at least depend on some parsing library.
That is not the unix philosophy lol that is a detail of the kernal
In 1978, Doug McIlroy documented a set of principles encapsulating the “characteristic style” that had emerged among Unix system users and developers
-
Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new “features”.
-
Expect the output of every program to become the input to another, as yet unknown, program. Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input.
-
Design and build software, even operating systems, to be tried early, ideally within weeks. Don’t hesitate to throw away the clumsy parts and rebuild them.
-
Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you’ve finished using them.
Expect the output of every program to become the input to another, as yet unknown, program. Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input.
Parsers
-
Not every file format has the complexity of JSON. And most of the files the kernel serves are either trivial enough to be parsed with a simple FSM or not meant to be parsed at all. No dev worth their weight in sawdust is gonna pull an external library just to help parse the space-separated numbers of /proc/uptime.
deleted by creator
