5 ms·

So you're trusting opscode to provide the primary centralized control system of your entire server ecosystem but you're concerned they might be embedding someth

• nicksergeant 13y ago
  It's not that you don't trust opscode, it's that it's possible that someone could hack opscode's installer script...
  • trotsky 13y ago
    just like they could replace a binary, backdoor the Makefile or hide something bad deep in the repo. And of course their hash of their signing key for their apt repo and any shasums are provided on the same webserver.
    • cmsj 13y ago
      Of course that is always a risk, but with most FOSS software being maintained in public revision control systems, it's difficult to truly hide something. Even if you discard the security angle of wget | bash (which you would be a foolish choice) there is the simple problem of repeatability. If you are deploying 50 new servers and OpsCode releases a new version of Chef after 25 of the servers have performed the wget, the next 25 will get a different client that might be incompatible with the server.
      • trotsky 13y ago
        For what it's worth, that curl install is a "beachhead" install. When you provision servers you load chef on them using knife bootsrap, which carefully ensures it installs the revision of chef on the server that you're using on the management workstation. You have to go out of your way to get a brand new release installed on a node if you haven't installed it on your workstation.