Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95849
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.67 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <fc0df908-0e9d-e748-70cb-9d9a6e8d4ee6@lsces.co.uk>
References: <616bb9ff-bcd1-fd70-b251-05b280b5003e@lsces.co.uk>
 <CANUQDCh=xC5G2FS2a-jm3aKATwV1BuOhd+AQiCq7tnMUvruFcA@mail.gmail.com> <fc0df908-0e9d-e748-70cb-9d9a6e8d4ee6@lsces.co.uk>
Date: Fri, 9 Sep 2016 13:35:17 +0200
Message-ID: <CAH-PCH5FadFFygmXQE35Fzr6sDniG8rdsnVvWA9FYE+404RYog@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0102d85e770b2b053c118a93
Subject: Re: [PHP-DEV] Modern practices ...
From: tyra3l@gmail.com (Ferenc Kovacs)

--089e0102d85e770b2b053c118a93
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Sep 9, 2016 at 1:00 PM, Lester Caine <lester@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 thei=
r
> >> > 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.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--089e0102d85e770b2b053c118a93--