2 ms·

> It's more susceptible to malicious input than 'docker pull' is. That said, it has a stronger trust story. What does that mean? Let's look at how 'docker pul

> It's more susceptible to malicious input than 'docker pull' is. That said, it has a stronger trust story. What does that mean? Let's look at how 'docker pull' and 'docker load' compare: - They're both loading an image into docker. - They're both NOT checking any signatures in any meaningful way. - All that's different about `docker pull` is that it's fetching directly from the network. How could 'docker load' possibly be more susceptible to malicious input? Clearly, there is never any circumstance in which it is safe to load arbitrary, untrusted content through docker. I fail to see how loading untrusted content from the network could be safer than loading untrusted content from disk.

ewindisch 12y ago
It's mostly in how Docker perform the 'docker load' and 'docker pull' that results in a different security story, not so much how it ultimately extracts the files and applies them to the filesystem. When you use 'docker pull', you're explicitly loading a specific tag and the layers associated with it. Docker 'load' doesn't load an image and a tag as specified by the user, it loads an arbitrary number of images and tags as specified in the provided archive. For one example of an actual vulnerability, up until Docker 1.3.3, it was possible for a 'docker load' to execute path traversal attacks based on malicious image IDs. This was largely mitigated by the 'docker pull' code and url semantics. There was still some risk from malicious registries, but again, mitigated by having a trusted registry behind TLS.