While it would be prudent to examine the script rather than just blindly execute it... I imagine most don’t (myself included).
They're fine for security and super convenient. I get why it's so popular - packaging and publishing debs is often going to be a lot more work, and now you're in the world of either maintaining a package repo or having to deal with an official one.
Creating a baseline .deb file takes at most 10 minutes if you know what you're doing. To know what you're doing, you need to spend ~2 hours once.
It's not rocket science (finding the documentation is tbh). :)
In this case, explicitly telling "this is my repository and this is the public key. gnupg the key, add this repository line, and get the packages" provides an end to end verified package pipeline. No .sh scripts to compromise.
If you keep your private keys on a network detached place and only plug your keys while signing stuff, things are pretty secure out of the box.
https://src.fedoraproject.org/rpms/5minute/blob/rawhide/f/5m...
Signing of packages is used to protect from malware.
Even something like nix runs all sorts of arbitrary side effects when installing packages: the main benefit isn’t preventing the side-effects but the various sandboxing tricks it uses.
I do admit that this sandbox is likely more for purity than security. Nonetheless while there may be exploits it is quite different than executing an installer or packages that have after-install scripts.
Also, I mainly use nix on Mac, where the sandbox is disabled by default and doesn’t work as well as the Linux sandbox, by all accounts.
I always read these files before building from source. Is this really so rare? Why wouldn't people read the scripts they're about to run?
> the various scripts inside Debian packages and RPMs
It's reasonable to assume package repository maintainers have ensured their packages are not malicious.
And, I doubt most people have the time or ability to read all the scripts that come with large software packages and ensure that they’re safe. For better or worse, executing code downloaded from the internet without verifying it manually is the norm these days.
You apt-get signed packages coming from official mirrors (at least I do). Most of the Debian packages, by very far, are also fully deterministic and reproducible. If someone serves a backdoored package, that's probably incredibly noisy, leaving lots of traces everywhere and evidence can be gathered.
When you curl, there's no way to know if you're the "lucky" one to get served malware by the server on that one curl call.
This is completely different.
PPAs and debs downloaded from a GitHub release page have all the same problems as curl | sh
# rpm -q --scripts bash
postinstall scriptlet (using <lua>):
nl = '\n'
sh = '/bin/sh'..nl
bash = '/bin/bash'..nl
f = io.open('/etc/shells', 'a+')
if f then
local shells = nl..f:read('*all')..nl
if not shells:find(nl..sh) then f:write(sh) end
if not shells:find(nl..bash) then f:write(bash) end
f:close()
end
postuninstall scriptlet (using <lua>):
-- Run it only if we are uninstalling
if arg[2] == "0"
then
t={}
for line in io.lines("/etc/shells")
do
if line ~= "/bin/bash" and line ~= "/bin/sh"
then
table.insert(t,line)
end
end
f = io.open("/etc/shells", "w+")
for n,line in pairs(t)
do
f:write(line.."\n")
end
f:close()
end
rpm -ip https://mojang.com/Minecraft-launcher.rpm
The checksums don’t really matter here: if I can compromise the package, I can also compromise the checksums.
Except then it's not the same idiom. Piping curl to a shell is not the same thing as downloading and running an installer, even if that installer happens to be a shell script. Part of the main problem is that the installation steps are ephemeral. It's nearly impossible to confirm that what was run when you installed it is what you see when you check the installation URL now, where now may be a week, a month or a year later.
> Which has all the same problems as curl | sh
No, I just god through outlining some of the ways it specifically is different in the prior comment. At a minimum, you know what launcher was installed, and what URL it's set to check, and what version it is in case there's a bug in the launcher. It shares some problems with piping an online script to a shell, but not all of them. You may think the ways in which they differ don't matter, but that's an opinion, and I hold a different one. They are different in real ways though.
It most certainly is not. Grabbing random code from some site is not the same as installing a package from a known repository which has been tested and inspected by a maintainer. Of course the latter isn't perfect, but it is way more assurance than the none whatsoever of a random script from an unknown source.
Either an Admin builds from source, an Admin installs a binary from a source they deem trustworthy, or you YOLO, download something sketchy to an older system and watch what your Network Analyzer/reverse engineering stack spits out.
App stores changed none of that in terms of fundamental activity one needs to do. They just lull users into a false sense of security because "someone else did it". I've run into too many devs who salivated over the idea of embedding cryptominers in game clones to believe it isn't done on a semi-regular basis.
Reminds me of early days in my career when my mentor and I were discussing user issues with a library we maintained. I didn't realize it at the time, but he was messing with me by suggesting we add some hooks to report usage statistics back to us and use that to improve things.
I was young and naive so excuse that I got really excited at the genius of the idea. If not for his wry smile, I would have happily run off and implemented just that.
What people run on their machine is no one's business but theirs. Undisclosed/non-consensual information leakage is unethical, and immoral. Period. I'm also not entirely on the status-quo of "accept the EULA or F off" form of disclosure or consent facilitation either. If someone reaches out, by all means, get the detailed info you need, but don't pull it. Let them push it. Other folk's machines don't become yours by virtue of executing some version of a computation you wrote once, no matter how badly Microsoft, IBM, Intel, and the FAANG's wish that were the case.
Note, this would be considered anti-thetical to most corporate or for-profit interests in the computing space; so don't be surprised if you get blowback or static for it.
This just isn’t true: app stores vary but they added some key changes — developers have a reputation to worry about, stores restrict what APIs you can call, and it provides a single place to force updates or pull malware. That’s not perfect, of course, but it’s better than just installing whatever you find online — Facebook et al. wouldn’t be upset with Apple if it wasn’t working.
Do you trust the Debian project? I mean, there’s reasons to trust them but if you don’t, then don’t run Debian.
If you do: the package repositories carry their chain of trust, since they’re signed by Debian maintainers- not the application developers themselves.
That’s a large distinction.
App stores didn’t give us trust; they have developers direct access to users and, crucially, the ability to charge for software- which was not a consideration for package managers before.
And Apple for the most part has been trying to carry the “burden” of ensuring trust, at a high cost.
- access clipboard
- mess with scrolling
- overlapping controls.