I am trying to design a deployment process for an enterprise level application. I have heard conflicting opinions on whether Composer can be used in the production environment.
I understand that running composer update would be a mistake since you can pull in untested versions. Instead in production it is recommend that only composer install is used.
So that being said, my biggest concern is security. How easy is man in the middle attack possible. Is it possible if packagist gets hacked that we can pull down hacked code?
I don't want to have a manual process in place where each time I deploy I have to manually bring the vendor file over. Currently Jenkins will move the source files to production. I don't want to version control the vendor folder if at all possible.
- Should I actually be concerned about security if I use
composer install.
- If I don't use composer in production, how do you suggest I deploy vendor files?
Yes, you should be concerned and try to understand which data transports are involved.
The current implementation of Composer does use a lot of checksums internally, but there is no package signing involved, so anything that gets downloaded during composer install might be potentially any software depending on which servers hosting either the software repository or TGZ/ZIPs, or are asked about metadata, are a valid target that could be tampered with to affect what you'd install.
Note however that this isn't only related to security. If you depend on the software packages being installable during your production deployment, it is even more likely that any of the mentioned servers is offline. How would you protect your deployment against any server outages of third party software hosting? The answer to this question is pretty simple: Host the software locally.
And this answer will also affect the security question: If you host the software packages locally, you can also audit these versions before making them available internally. Depending on which level of security you need, you'd either check every single version you get, and restrict the available versions to only the few you are able to check, or you might create a more generous way of asserting that the software you get is fetched from the original Git repository, and create the ZIP version of the software locally (ZIPs are more convenient if you don't intend to further develop the packages IMO).
There are only two software products known that may help here: Toran Proxy is a commercial product from Jordi Boggiano (one of the Composer core developers) that is supposed to also help fund the development of Composer and the infrastructure. The other software is Satis, which also allows creating local copies of the packages you use.
Disclaimer: My answer probably does not get into the finer details, and may present some details too brief or possibly wrong. It is not meant to address every security detail, but rather give a broad overview. The security and authenticity checking of software packages is one topic being in discussion for quite some time (see https://github.com/composer/composer/issues/38 for example), but without any result so far.
To prevent directory listings (for security purposes, for example), you should remove the Indexes keyword from every Options directive in your configuration file.
on your apache server, you can use:
add this to your .htaccess file
<Directory />
Options -Indexes
</Directory>
