The report (rudely, but) correctly, points out that the recommended way of installing the script, by getting it via curl and piping it into an interpreter, is a security risk in the event that the source gets hacked and starts serving malicious code. That's true - I agree.

But hang on a minute, Composer is a package manager for a programming language. The whole point of Composer is that you download other people's code and then include it straight into some executable of your own! You could literally be pulling in 50 different packages, each of which suffers from the exact same vulnerability - if the source is compromised, you are executing very untrusted code (instead of merely we'll trust it because it's convenient code).

I'm not saying you shouldn't use package managers, nor am I saying that signing scripts/executables is a bad thing, but I am saying you should be a b[...]]]> Here's a bug report from the Composer project: https://github.com/composer/getcomposer.org/issues/76

The report (rudely, but) correctly, points out that the recommended way of installing the script, by getting it via curl and piping it into an interpreter, is a security risk in the event that the source gets hacked and starts serving malicious code. That's true - I agree.

But hang on a minute, Composer is a package manager for a programming language. The whole point of Composer is that you download other people's code and then include it straight into some executable of your own! You could literally be pulling in 50 different packages, each of which suffers from the exact same vulnerability - if the source is compromised, you are executing very untrusted code (instead of merely we'll trust it because it's convenient code).

I'm not saying you shouldn't use package managers, nor am I saying that signing scripts/executables is a bad thing, but I am saying you should be a bit sensible about evaluating security risks.]]>