On Fri, Sep 9, 2016 at 1:00 PM, Lester Caine <les...@lsces.co.uk> wrote:
> On 09/09/16 11:30, Niklas Keller wrote: > >> Back to PEAR ... what happens if I simply install a copy of composer > >> > centrally and rename it 'PEAR'. > > > > Why rename it to PEAR? It's a different tool. Just call it Composer as > it's > > named. > > My point was just that as has already been established. composer can do > the same thing as PEAR. All that matters is that everybody is working > from the same global installation. The composer.json/composer.lock that > controls a particular installed application is secure to that > application not an individuals account. > usually what's best it that you learn the new tool and apply it to your use case instead of trying to make it work the same way as your previous tool blindly. > > >> > composer.phar simply gets installed > >> > centrally and any new tech has access without having to install their > >> > own copy. > > > > That's entirely fine as said. New tech should still install their own > > version of the repository and install the dependencies there. > > Then you have never had a full security audit of your systems! A new > user should NEVER install their own version of anything relating to the > running system. THAT is a potential hole in the security of the system. > The new user should simply be given access to the locked down code > already installed. > > not sure I understand who is a user in that example. are you arguing that your developers shouldn't ever be allowed to change code? (allowing them to install dependencies is basically the same as allowing them to change code) if that's true why would you have developers in the first place? changing code is fine, as long as you can audit those changes before it goes to production and if you can make sure that the audited code will be the same that goes to production. the current industry best practice is to separate the build and deployment steps, so you can inspect and verify your application before those two steps. with composer that usually means that you won't ever execute composer install on your production machines, but installing your dependencies is part of your build process which results in an artifact (which can be anything from a directory of files, or a debian package, a docker container or an amazon AMI) which then can be inspected, installed in isolation, put through automated testing or manual QA then you can release it without any chance that it will be different from what you ispected. I'm not saying that everybody needs such complex release workflow, but you sounded as secure system would be only possible with a system wide PEAR install but not with composer or application specific dependency installation in general. but please, this is really offtopic on this list. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
