3 ms·
Morally curl | bash is no different to downloading a package from the provider directly, or adding a repository managed by the provider. As people are well awar
by Macha 3y ago
Morally curl | bash is no different to downloading a package from the provider directly, or adding a repository managed by the provider. As people are well aware, it will not protect you from the software provider being malicious. Neither will obtaining that proprietary installer from adobe.com for Windows/Mac. I'd argue the security level goes from worst to best:
1. curl | bash = npm/pip/cargo/whatever install = developer provided package repositories = proprietary software installers
2. App stores from proprietary OS vendors. You still don't really know what's in the software, but at least you already have to trust Apple/Microsoft if you're using those OSes and they can remove detected bad behaviour globally.
3. Package repositories from trusted traditional linux repositories. You can view the purported source code of the build, plus there is now someone who can block bad packages.
4. Package repositories from linux repositories with public build processes. Not just the scripts, but being able to see the execution of the build and have it signed to prove where it came from (as opposed to Joe packager's personal machine then FTPing it up).
5. Making your own copy of every piece of software, auditing the entire source code, building it in an environment you control, and keeping the artifact you then sign somewhere you control. This is so much work that nobody does this.
People like to tut tut at curl | bash, but most of them are happy to do everything else in line 1, and maybe trust line 2. This is not the position of safety and moral superiority it's portrayed as.
- tracker1 3y ago6. use flatpak/snap/appimage that run in relative isolation from the core os.
- Macha 3y agoFlatpak itself is really a different dimension of security to that discussed here. It solves a different problem (the software might have exploitable security vulnerabilities) than the one discussed here (the software itself might be malicious). Running software that secretly phones home everything you do in the program is still going to be a problem in flatpak.
- sigotirandolas 3y agoI wouldn't say that it's a different dimension. If you install a Flatpak (and you check that the permissions it asks for make sense), the application will not be able to do as much damage even if it's malicious. Furthermore I'd argue that a big reason (2) > (1) is not that Google/Apple are that great at detecting malicious applications, but that malicious applications also have a harder time getting too many permissions with their system. And furthermore, a reason why "curl | bash" is bad, is that you are piping arbitrary code straight into a shell, which gives no chance for the system to know which permissions the code needs. Whereas if you do a "curl ... && flatpak install ...", it can.
- prmoustache 3y agoThis argument is moot once you allow said software to have access to your files...which you will usually have to if you want that software to be useful to you.
- didntcheck 3y agoAccess scoped to a directory is a big improvement over an unsandboxed process. Any unprivileged program can trivially steal your browser sessions by reading your profile dir, but with Flatpak it would be possible to only grant it access to your "documents". I don't know if this is currently done in practice though, or if it's still common to just grant it full access to ~, including dotfiles. Even if so, the technology is there, showing a clear route to improvement
- classichasclass 3y agoIf you're on a non-standard architecture, you're absolutely doing a lot of #5. For that matter, I build my own Firefox even though Fedora offers a package because I like the concept of doing so, I can submit fixes, and I can do local optimizations. It's a lot of work but it's hardly infeasible.
- Macha 3y agoDo you also build your own kernel, glibc, dnf, openssl, pipewire/pulseaudio, systemd, ffmpeg, ffmpeg extensions, gtk, gcc, rustc, llvm, python, coreutils, ca certificate bundle, x11/wayland, clang, nodejs? I'm guessing no. So your overall security posture is line 3, where you're trusting fedora to be the gatekeeper for you.