3 ms·

In this context we’re not talking about .debs from an official repository PPAs and debs downloaded from a GitHub release page have all the same problems as cur

In this context we’re not talking about .debs from an official repository PPAs and debs downloaded from a GitHub release page have all the same problems as curl | sh

kbenson 6y ago
Even if you aren't running official debs or RPMs, you're still quite a bit above running a build script off the web. A deb or RPM will include a manifest with checksums, which you can at a minimum use to confirm whether some post-isntall script or process changes an included file (such as removing or cleaning a malicious script that was included). In the case of RPM (at least, I'm not implying debs don't do this, just that I'm not as familiar with them) you can actually query any pre/post install scripts that were shipped with it as well: # 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 Even a downloaded package that's not signed is far more auditable after the fact than executing arbitrary commands from a remote source.
- fiddlerwoaroof 6y ago
  I can also pipe the script into a file and read it: it’s much easier to vet a simple shell script than an rpm or whatever anyways. But, my point just is that the vast majority are going to trust the package they downloaded to be safe: most people installing Minecraft on Linux from a .rpm they downloaded from Mojang aren’t going to audit the RPM, they’re just going to install it, maybe even with (it’s been a while since I’ve used RPMs, so my syntax is probably off here): rpm -ip https://mojang.com/Minecraft-launcher.rpm Which has all the same problems as curl | sh The checksums don’t really matter here: if I can compromise the package, I can also compromise the checksums.
  - kbenson 6y ago
    > I can also pipe the script into a file and read it 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.
codedokode 6y ago
You are right. Adding third-party PPAs is not secure (it is because Linux distributions are not friendly to third-party software), that's why it is always better to download and unpack such software manually without running it as root.

In this context we’re not talking about .debs from an official repository PPAs and debs downloaded from a GitHub release page have all the same problems as curl | sh

kbenson 6y ago

Even if you aren't running official debs or RPMs, you're still quite a bit above running a build script off the web. A deb or RPM will include a manifest with checksums, which you can at a minimum use to confirm whether some post-isntall script or process changes an included file (such as removing or cleaning a malicious script that was included). In the case of RPM (at least, I'm not implying debs don't do this, just that I'm not as familiar with them) you can actually query any pre/post install scripts that were shipped with it as well: # 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 Even a downloaded package that's not signed is far more auditable after the fact than executing arbitrary commands from a remote source.

fiddlerwoaroof 6y ago
I can also pipe the script into a file and read it: it’s much easier to vet a simple shell script than an rpm or whatever anyways. But, my point just is that the vast majority are going to trust the package they downloaded to be safe: most people installing Minecraft on Linux from a .rpm they downloaded from Mojang aren’t going to audit the RPM, they’re just going to install it, maybe even with (it’s been a while since I’ve used RPMs, so my syntax is probably off here): rpm -ip https://mojang.com/Minecraft-launcher.rpm Which has all the same problems as curl | sh The checksums don’t really matter here: if I can compromise the package, I can also compromise the checksums.
- kbenson 6y ago
  > I can also pipe the script into a file and read it 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.

codedokode 6y ago

You are right. Adding third-party PPAs is not secure (it is because Linux distributions are not friendly to third-party software), that's why it is always better to download and unpack such software manually without running it as root.