15 ms·

curl -s http://getcomposer.org/installer http://getcomposer.org/installer | php is creepy. Never ever run other people's code without at least giving it a glan

by aw3c2 14y ago

curl -s http://getcomposer.org/installer http://getcomposer.org/installer | php is creepy. Never ever run other people's code without at least giving it a glance.

codeguy 14y ago
haha. Always good advice. But I checked. It's fine :)
- chrismsnz 14y ago
  It's fine now until someone hacks their site or poisons their DNS.
  - anthonyb 14y ago
    Or writes a script which checks the user agent and only serves up malware to curl. Or the second time that an IP address hits it. Or something else that you haven't thought of. Update: Such as doing something nasty to http://getcomposer.org/composer.phar http://getcomposer.org/composer.phar instead - a 520KB php file that the first script downloads and runs without even md5ing first. Did you audit that too? Did you understand everything that it was doing?
  - larrys 14y ago
    Or social engineers their registrar and changes their dns.
zdw 14y ago
RVM's installation is similar: https://rvm.io/rvm/install/ https://rvm.io/rvm/install/ A far cry from the safer/verified "download this and check it's MD5 checksum" method that I'd prefer. Seriously, fixing package management so we can continuously integrate arbitrary code would be great. Getting arbitrary OS package creation to be almost as easy as pushing code to GitHub seems like a very worthy goal.
- anthonyb 14y ago
  md5 is not going to protect you from much, especially if the md5 checksums are hosted on the same server. Also, pushing random code via apt-get is not going to win you any sysadmin friends. They like their servers to be stable, and their packages to be well tested.
  - zdw 14y ago
    Seeing as you can remove said code via apt, you'd likely win them over compared to the alternative of being told to install compilers or some other non package managed software bundler like cpan/rvm/npm that can't be canned and easily deployed.
    - anthonyb 14y ago
      But why would you remove it? Because whatever you've installed has broken. Much better not to be broken in the first place.
      - adient 14y ago
        It seems you live in an idyllic world far, far away from reality.
- mark_story 14y ago
  For the longest time the installation instructions for NPM were almost exactly the same. But its worse when PHP does it :)
- brohee 14y ago
  It's not the nineties anymore, MD5 doesn't protect you from much, and especially not from the author of the original package creating an alternate version. Viable verification is based on an unbroken hash (preferably SHA-(256|384|512), but SHA1 still not broken even it it's definitely too short nowadays. And the hashes need to be distributed properly, either PGP signed or hosted on a trusted TLS protected site... Yet many projects still distribute MD5 hashes, thinking it got any value.
wvenable 14y ago
Reminds me of how you get mysqltuner: wget mysqltuner.pl perl mysqltuner.pl (Yes, they actually have a .pl domain for it)
1amzave 14y ago
Indeed, especially coming after this further up the page: > Never ever (ever) trust foreign input introduced to your PHP code. Where'd I put that sense of irony...
- ecaron 14y ago
  Except that there's a significant difference between "trust" of input from the user vs. "trust" of the software stack you use as a foundation. Unless you've read every line of the Linux kernel, we all succumb to the later point sooner or later.
timaelliott 14y ago
That's really just a question of trust. If you know what Composer is, you trust it. 'apt-get install whatever' is just as magically scary and dangerous.
- Kudos 14y ago
  No it isn't, there's GPG signing and things going on there.
  - Udo 14y ago
    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.
    - Dylan16807 14y ago
      The difference is the same as between http and https.
      - Udo 14y ago
        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.
      - jasonlotito 14y ago
        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?
deleted 14y ago
[deleted]
mcantor 14y ago
Yeah... only idiots "sudo aptitude install" without reading and building from source first!
- dsl 14y ago
  You really can't tell the difference between blindly executing input from an insecure HTTP connection, and installing packages with a tool that verifies cryptographic signatures against known good keys shipped with your distro? Mr. Cantor, I have added to the list of people to never hire I keep in my notebook.
  - huhtenberg 14y ago
    The risk of picking up malicious executable from the legit server is far higher than that of picking up a malicious executable from an impersonating server. Practically speaking.
    - soc88 14y ago
      So what? The package manager will not install it. So it is still thousand times better than downloading random things from the net.
  - mcantor 14y ago
    So? Who says the verified package isn't malicious? My point isn't about cryptography, it's about complexity. Unless you personally read through every line of code, how do you really know that there isn't something in there waiting to screw you over?
    - aw3c2 14y ago
      I trust my system's package maintainers and the signing makes sure that it is them. I do not trust a random website that could easily be MITMd.
      - VMG 14y ago
denysonique 14y ago
In terms of security this is no different than executing someones binary or building a big code base.
wilmoore 14y ago
If you don't like that command, do this instead: > curl -s http://getcomposer.org/composer.phar -o $HOME/local/bin/composer ; chmod +x $HOME/local/bin/composer Assuming that $HOME/local/bin is in your $PATH, the current user will have a "composer" command available.

by aw3c2 14y ago

curl -s http://getcomposer.org/installer http://getcomposer.org/installer | php is creepy. Never ever run other people's code without at least giving it a glance.

codeguy 14y ago

haha. Always good advice. But I checked. It's fine :)

chrismsnz 14y ago
It's fine now until someone hacks their site or poisons their DNS.
- anthonyb 14y ago
  Or writes a script which checks the user agent and only serves up malware to curl. Or the second time that an IP address hits it. Or something else that you haven't thought of. Update: Such as doing something nasty to http://getcomposer.org/composer.phar http://getcomposer.org/composer.phar instead - a 520KB php file that the first script downloads and runs without even md5ing first. Did you audit that too? Did you understand everything that it was doing?
- larrys 14y ago
  Or social engineers their registrar and changes their dns.

zdw 14y ago

RVM's installation is similar: https://rvm.io/rvm/install/ https://rvm.io/rvm/install/ A far cry from the safer/verified "download this and check it's MD5 checksum" method that I'd prefer. Seriously, fixing package management so we can continuously integrate arbitrary code would be great. Getting arbitrary OS package creation to be almost as easy as pushing code to GitHub seems like a very worthy goal.

anthonyb 14y ago
md5 is not going to protect you from much, especially if the md5 checksums are hosted on the same server. Also, pushing random code via apt-get is not going to win you any sysadmin friends. They like their servers to be stable, and their packages to be well tested.
- zdw 14y ago
  Seeing as you can remove said code via apt, you'd likely win them over compared to the alternative of being told to install compilers or some other non package managed software bundler like cpan/rvm/npm that can't be canned and easily deployed.
  - anthonyb 14y ago
    But why would you remove it? Because whatever you've installed has broken. Much better not to be broken in the first place.
    - adient 14y ago
      It seems you live in an idyllic world far, far away from reality.
mark_story 14y ago
For the longest time the installation instructions for NPM were almost exactly the same. But its worse when PHP does it :)
brohee 14y ago
It's not the nineties anymore, MD5 doesn't protect you from much, and especially not from the author of the original package creating an alternate version. Viable verification is based on an unbroken hash (preferably SHA-(256|384|512), but SHA1 still not broken even it it's definitely too short nowadays. And the hashes need to be distributed properly, either PGP signed or hosted on a trusted TLS protected site... Yet many projects still distribute MD5 hashes, thinking it got any value.

wvenable 14y ago

Reminds me of how you get mysqltuner: wget mysqltuner.pl perl mysqltuner.pl (Yes, they actually have a .pl domain for it)

1amzave 14y ago

Indeed, especially coming after this further up the page: > Never ever (ever) trust foreign input introduced to your PHP code. Where'd I put that sense of irony...

ecaron 14y ago
Except that there's a significant difference between "trust" of input from the user vs. "trust" of the software stack you use as a foundation. Unless you've read every line of the Linux kernel, we all succumb to the later point sooner or later.

timaelliott 14y ago

That's really just a question of trust. If you know what Composer is, you trust it. 'apt-get install whatever' is just as magically scary and dangerous.

Kudos 14y ago
No it isn't, there's GPG signing and things going on there.
- Udo 14y ago
  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.
  - Dylan16807 14y ago
    The difference is the same as between http and https.
    - Udo 14y ago
      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.
    - jasonlotito 14y ago
      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?

deleted 14y ago

[deleted]

mcantor 14y ago

Yeah... only idiots "sudo aptitude install" without reading and building from source first!

dsl 14y ago
You really can't tell the difference between blindly executing input from an insecure HTTP connection, and installing packages with a tool that verifies cryptographic signatures against known good keys shipped with your distro? Mr. Cantor, I have added to the list of people to never hire I keep in my notebook.
- huhtenberg 14y ago
  The risk of picking up malicious executable from the legit server is far higher than that of picking up a malicious executable from an impersonating server. Practically speaking.
  - soc88 14y ago
    So what? The package manager will not install it. So it is still thousand times better than downloading random things from the net.
- mcantor 14y ago
  So? Who says the verified package isn't malicious? My point isn't about cryptography, it's about complexity. Unless you personally read through every line of code, how do you really know that there isn't something in there waiting to screw you over?
  - aw3c2 14y ago
    I trust my system's package maintainers and the signing makes sure that it is them. I do not trust a random website that could easily be MITMd.
    - VMG 14y ago

denysonique 14y ago

In terms of security this is no different than executing someones binary or building a big code base.

wilmoore 14y ago

If you don't like that command, do this instead: > curl -s http://getcomposer.org/composer.phar -o $HOME/local/bin/composer ; chmod +x $HOME/local/bin/composer Assuming that $HOME/local/bin is in your $PATH, the current user will have a "composer" command available.