On Thu, May 12, 2016 at 11:59 AM, Danny Rosen <drosen(a)pivotal.io> wrote:

Thanks. This is helpful! I'd like get a better understanding of the
following:

Why would an operator set their environment to be disconnected from the
internet if they wanted to enable their users to run arbitrary binaries via
a buildpack?

I don't think it wouldn't allow them to run arbitrary binaries, but it
would allow them to run arbitrary build packs. If you divorce the binaries
from the build pack, you can control the binaries separate in a corporate
IT managed, not public repository of binaries. Then users can use any
build pack they want so long as it points to the blessed internal repo of
trusted binaries.

Dan

For if an operator wanted to provide users the flexibility of executing
arbitrary binaries in buildpacks, custom buildpacks can be implemented via
an environment with internet *or* by providing a proxy
<http://docs.cloudfoundry.org/buildpacks/proxy-usage.html> that would
allow custom buildpacks to be deployed
<http://docs.cloudfoundry.org/buildpacks/custom.html#deploying-with-custom-buildpacks>
with an app.

On Thu, May 12, 2016 at 11:37 AM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

See responses inline:

On Thu, May 12, 2016 at 9:04 AM, Danny Rosen <drosen(a)pivotal.io> wrote:

* One of the key value propositions of a buildpack is the lightweight
process to fork and customize a buildpack.
*The inclusion of binaries makes buildpack customization a much heavier
process and less end user friendly in a number of ways.*
-- I'm not sure I agree with this point and would like to understand
your reasoning.

I may be missing something but it was my understanding that buildpacks
with binaries included must (unless checking all binaries into git) be
added as admin buildpacks which non admin users of CF cannot do.
Therefore, if I am a simple user of cloud foundry I cannot customize a
buldpack for my one off need without involving an administrator to upload
and manage the one off buildpack. If binary dependencies were instead
managed in a way like Daniel proposes the process would simply be to fork
the buildpack and specifying that git repo when pushing. Completely self
service without admin intervention. Making it a lighter weight process.

* For some of my customers the binary inclusion policies is too

restrictive.
-- It's hard for me to understand this point as I do not know your
customers' requirements. Would you mind providing details so we can better
understand their needs?

I've attempted to express that need previously here:
https://github.com/cloudfoundry/compile-extensions/issues/7 I don't
view this as a major issue but I think it could be something to consider if
buildpacks binary management is being reconsidered.

Hope those additional details help

Mike