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.]]> https://blog.asgaard.co.uk/2012/10/12/what-is-indy-library Fri, 12 Oct 12 16:43:21 +0000 https://blog.asgaard.co.uk/2012/10/12/what-is-indy-library Browsing my logs, I see a bot with the user agent "Mozilla/3.0 (compatible; Indy Library)" doing some pretty interesting things.

It appears to be a distributed bot which dictionary attacks login forms. That is to say, it attempts to hack your site. It's (incorrectly) identified mine as Wordpress, but maybe it attacks other CMSs too.

I have a honeypot set up to make this site look like Wordpress which logs login attempts. You can see the results of this here, the Indy Library bot is the first to take the bait and is currently filling up the data quite quickly (although not excessively).

It's using a whole bunch of different IPs:

217.128.175.91
80.35.16.63
188.13.39.226
64.61.155.42
90.182.73.81
71.224.57.62
212.183.165.15
80.59.98.59
2.112.195.83

But instead of using the IPs, as it identifies itself via user agent, you can block it easily with an .htaccess rule

RewriteCond %{HTTP_USER_AGENT} Indy\ Library [NC]
RewriteRule .* - [F]