[vitonsky]

Just for context. DuckDB team is consistently ignores any security practices.

The single one method how to install DuckDB on laptop is to run

`curl https://install.duckdb.org | sh`

I've requested to deliver CLI as standard package, they have ignored it. Here is the thread https://github.com/duckdb/duckdb/issues/17091

As you can see that it isn't single slip due to "human factor", but DuckDB management consistently puts users at risk.

[throwaway127482]

Genuine question: why is `curl https://trusted-site.com | sh` a security risk?

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

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. Either way, you are depending entirely on the legitimacy of their domain right?

[dansmith1919]

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.

[tomsmeding]

It is sometimes possible to detect server-side whether the script is being run immediately with `| sh` or not. The reason is that `sh` only reads from its input as far as it got in the script, so it takes longer to get to the end than if you'd curl show the result in the terminal directly (or pipe it to a file).

A server can use this to maliciously give you malware only if you're not looking at the code.

Though your point about trust is valid.

[kevinrineer]

`curl URL | sudo sh` doesn't have a means of verification of what the contents of the URL points to.

Sure a binary can be swapped in other places, but they generally can be verified with hashes and signatures. Also, a plaintext install script often has this problem in another layer of recursion (where the script usually pulls from URLs that the runner of the script cannot verify with this method)

[0xbadcafebee]

> 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")

All you have to do is copy and paste that snippet, and the same thing will happen as the one-liner, except it will only work if the sha256sum is valid. Now this isn't perfect of course, we should be using artifacts signed by a private key. But it's better than just praying.

[mdaniel]

  curl -f

I'm super sad they didn't make --fail the default, and people that don't care could opt-out with --no-fail

[galaxy_gas]

The PHP primary package manager does this similar in what you write - https://getcomposer.org/download/

It is amazing that a duckdb could be worse than decade old PHP for something such as this.

[zahlman]

> 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-...)

[vitonsky]

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

[riku_iki]

> On linux it looks like `apt install python3`.

for MacOS they have it in brew, which is also you can use on linux, also it is available in nix.

I think the problem is that there are so many linux distros with their own package repositories, that it is very untrivial task to include package into most of them if maintainers are not proactively interested.

[Ekaros]

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...

[speedgoose]

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.

[themafia]

> 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.

[artemisart]

Do you know about other security issues? If it's only about curl | sh it really isn't a problem, if the same website showed you a hash to check the file then the hash would be compromised at the same time as the file, and with a package manager you still end up executing code from the author that is free to download and execute anything else. Most package managers don't add security.

[0cf8612b2e1e]

They also publish binaries on their GitHub if you prefer that.