No it isn't, there's GPG signing and things going on there.

That's really just Cargo Cult security, isn't it? Signed packages can just as easily be malicious. In fact a repository server could be a much worthier target for the injection of bad code than a single, relatively obscure web project.

The repository doesn't have any access to the developer's private key. That's exactly the attack that they're designed to mitigate.

The difference is the same as between http and https.

Exactly. SSL doesn't guarantee that the content is benign either. But there is also a key difference when it comes to software distribution. On a typical web connection you worry about 3rd parties observing your content and maybe even spoofing it later (e.g. stealing your cookies), but as far as downloads are concerned your main worry is actually content integrity. This integrity is threatened by both malicious publishers and outside attackers injecting malicious code into otherwise benign software - having a GPG signature alongside your rpm does (almost) nothing to mitigate that risk.

Not sure if you are trying to make a joke (and if so, it's incredibly subtle), or you are being serious. In case you are serious, to explain how HTTPS as it's used means anything about the trust-worthiness of the two parties involved?

Look at the original post. "curl -s http://getcomposer.org/installer | php" It's not just about trusting Composer, it's about trusting every point between you and their server. If I want to know that I am actually executing Composer I need to use a secure download method.

I don't disagree with you, but if you've got someone actively trying to exploit you sitting between you and the Internet, you've got bigger problems.

Someone trying to find an exploit is a bigger problem than giving them one?

Oh, definitely. If someone has a launched a targeted attack against you and they already have the ability to seamlessly view and modify your internet traffic, you are in pretty serious trouble whether you download your development tools from wget or apt-get.

Except that apt-get will check GPG signatures and detect that kind of attack. How is a MITM attack going to find a 3rd party's private key?

I'm looking at the post you replied to. So maybe you replied to the wrong post, or ignore context and tried to be witty or smart.

In context, what you say makes no sense.

Regardless, https would be better, but if you are that nervous as you suggest you are, then https doesn't solve your problem either. Neither does some hash thrown up on some site for you to compare against.

Here, how about I summarize my view of the conversation for you.

  aw3c2: 'curl | php' is creepy
  timaelliott: apt-get is just as scary
  kudos: no, it has signing
  udo: that's cargo cult
  me: no, it protects like https (meaning it authenticates and stops MitM)

I was responding perfectly in context to point out how the protections apt-get have are useful. I also tied it back into the original comment but you can ignore that part if you like. I don't know why you think I was 'trying to be witty' and ignoring context.

Ahh, gotcha, that better explains it.

Still, https doesn't validate anything. You could add a certificate, but then that only means you are talking to the server assigned the cert, not that the actual package is good.

I still stand by what I said: mountain and mole hills.

It does not help you if the originating server has been hacked, which is by far the most likely attack vector (after people being assholes on the internet or making mistakes in their script).

Protecting against that is the whole fucking point of using things like apt-get/PEAR and GPG/code signing.

Signed packages can be just as malicious, but the security of the mechanism relies on the signer not wanting to do jail time, thus protecting his secrets and not signing stuff he doesn't trust.