-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Consider support for auto-restaging of vulnerable droplets.TUF helpful ? #231
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Thinking it through, I now realize that the link between TUF and the java-buildpack artifact downloading is a bit streched: even though the repository is designed so that the latest available libs are visible as candidate when staging a java app, droplets are immutable, and therefore don't really update under the responsibility of the java buildpack. Therefore CF apps are hardly exposed to TUF targetted attacks, unless we consider an app restaging as an update process that could suffer from these attacks and benefit from TUF mechanisms. However, currently the restaging of an app is a manual operation, and cloudfoundry does not yet automate the detection that new updates are available in the java-buildpack easy mode, and that a staging could be desireable. So while related to the java-buildpack and its "easy mode" that provides ability to serve new dependencies, this discussion should rather be made wider with MEGA/runtime/buildpacks team as a way to autodetect droplets that would require a restaging to benefit from pending available updates of some of their dependencies. |
Added tracker issue - https://www.pivotaltracker.com/story/show/103661354 |
@gberche-orange The wider buildpacks team is reviewing this. I'm tempted to close this and simply handle it once a platform-wide system is delivered. Thoughts? |
Thanks @nebhale for your review of this suggestion. Do you have a pointer to a story on the buildpacks / MEGA tracker that could be followed ? If so, then sure it makes sense to close this conversation here. |
These problems are tricky, asTUF's list of attacks illustrates, and as the events of the last few years underscore. So I'm glad to see TUF brought into a conversation of secure Java packaging, installation, building and deployment. Any updates on updating? Any pointers to a broader platform discussion of this? |
At this point we're not going to deal with this problem in the Java Buildpack. With the advent of Cloud Native Buildpacks and their more explicit dependency management future concerns about this will be handled there. |
In addition to cloudfoundry/java-buildpack-dependency-builder#6 to prevent injection of malicous code into the binary repository, I'm wondering how much The
Update Framework (TUF) can be beneficial to the java buildpack when running in the easy or expert mode, especially to protect against the following attacks.
Is the HTTPS transport and high availability/throughput/Dos prevention of AWS S3 sufficient ? What about in the case of the expert mode, how hard is it reach such level in a private setting ?
Let me know if you prefer this discussion to happen over cf-dev@ instead.
The text was updated successfully, but these errors were encountered: