I assume OP's point is "you're running a random script directly into your shell!!"

You're about to install and run their software. If they wanted to do something malicious, they wouldn't hide it in their plaintext install script.

> Like, I don't see how it's different than going to their website, copying their recommended command to install via a standard repo, then pasting that command into your shell.

Suppose the site got compromised. If you separately explicitly download the install script first, in principle you can review it before running it.

Same deal with installing Python source packages (sdists). Arbitrary code included in the package runs at installation time (with the legitimate purpose of orchestrating any needed build steps, especially for non-Python code, which could be arbitrarily complex). This is worse than importing the installed code and letting it run whatever top-level code, because the entire installation is normally automated and there's no point where you review the code before proceeding. We do generally accept this risk in the Python ecosystem, but demanding to install only from pre-built wheels is safer (it just isn't always possible).

(Pip has the problem that this still happens even if you use its "download" command — because it wants to verify that building the project would produce a package with a name and version that match what it says in the file name and/or other metadata, and because it wants to know what the dependencies are — and in the general case it's permitted to depend on the build process to tell you this, because the system for conditional-on-platform dependencies isn't powerful enough for everyone's use case. See also: https://zahlman.github.io/posts/2025/02/28/python-packaging-...)

> Fundamentally, doesn't the security depend entirely on whether https is working properly? Even the standard package repos are relying on https right?

They should only need http. You don't need https at all if your package is signed. The package/installer/app/etc could come from anywhere, modified by anyone, at any level. But if it's not signed by the dev's private key (which only exists on their laptop [or hardware token], protected by a password/key manager), it's invalid. This avoids the hundred different exploits between the dev and the user.

What's actually crazy about this is, if you're already making the user do a copy and paste, it doesn't have to be one line. Compare that line above, to:

  (set -eu; tmpf="$(mktemp)"; [ -w "$tmpf" ] &&
  curl https://install.duckdb.org/ -o "$tmpf" &&
  echo "d5d91c69a874ef99c30cf36654f623ed9c423ed0e210dca229744ce4d3b273d0 *$tmpf" | sha256sum -c - &&
  bash "$tmpf")

Current incident confirms that we can't trust to authors of DuckDB, because they can't evade a trivial phishing attack.

Tomorrow they will do it again, and attackers will replace binary files that users download with this random script. Or this script will steal crypto/etc.

To make attack vector difficult for hackers, it's preferable to download any software as packages. On linux it looks like `apt install python3`.

The benefits is

1. Repositories are immutable, so attacker can't replace binary for specific version, even if they will hack all infrastructure of DuckDB. Remote script may be replaced anytime to run any code

2. Some repositories have strict review process, so there are external reviewers who will require to pass security processes to upload new version

Running code as privileged user is always a risk.

Running scripts even more so.

One day someone might decide simply to exploit whatever trust they have.

Actually I wonder how much black market would pay for rights to change reasonable popular script like that...

I also don’t know why using a unix pipe instead of saving in the file system and executing the file is a significant security risk. Perhaps an antivirus could scan the file without the pipe.

> depend entirely on whether https

> depending entirely on the legitimacy of their domain

Just move the phishing attack down each step of your dependency chain.