If your argument is that it is too easy to share then you are going to have a hard time winning over users.
But honestly how hard do you think it is to integrate secure builds into a docker system? I would just stand up a private docker repository and lock the build system to that, problem solved. Or docker could roll out an update to leverage the existing namespaces and combine that with a user controlled whitelist of public key & namespace pairs. The reason docker has enjoyed this much success is because they understand sharing is #1.
> Or docker could roll out an update to leverage the existing namespaces and combine that with a user controlled whitelist of public key & namespace pairs.
Could, but haven't.
> The reason docker has enjoyed this much success is because they understand sharing is #1.
Except they have fought tooth and nail against a standardized specification until App Container Specification was released. Docker isn't about "sharing", it's about vendor lock-in.
Thanks for sharing, I've seen appc mentioned in a few comments, I'll check it out properly tomorrow. You also raise a good comment about blindly trusting containers which, despite having concerns about this in the past, regrettably I didn't touch on.
Creating your own base image is really the only way to ensure the base is trustable.
And to that end -- App Container Specification has image discovery and downloading covered[1]
[1] https://github.com/appc/spec/blob/master/SPEC.md#app-contain...