5 ms·

Hacking aside, Docker is an invitation to trouble. Anybody can publish a binary blob, and users are expected to blindly trust it. It's centralized. It doesn't h

Hacking aside, Docker is an invitation to trouble. Anybody can publish a binary blob, and users are expected to blindly trust it. It's centralized. It doesn't have a context of "trustworthiness" yet I don't recall docker ever warning me that the image I'm downloading could have been the work of any person. Shortcuts all around -- kind of reminds me of MongoDB. Sad it's the primary player...

speedplane 7y ago
> Docker is an invitation to trouble. Anybody can publish a binary blob, and users are expected to blindly trust it How is this issue specific to Docker? Anyone can download a random library off github, use a shady linux distribution, or install utility tools loaded with spyware. I don't think Docker aims to solve issues relating to trusting upstream software. It's a tool to help package applications, just like how tar allows you to package files. What you put in it is up to you.
- bayareanative 7y ago
  That's a strawman because the shriekingly-obvious difference is ease of facilitation. With Docker, it's a mere couple of commands to pull a box and run it. Docker weakens trust because it lets anonymous people, as well as trusted ones, upload images that can be immediately run... but without a proper chain-of-custody, QA or assurance that an image hasn't been manipulated on Docker's side. It's spray-and-pray DevOps. Image integrity has to be solved on Docker's side with end-to-end integrity or it's all for naught... this is something that cannot be solved within a container or separate from Docker, it must be universal, mandatory and trustworthy.
  - speedplane 7y ago
    > Docker weakens trust because it lets anonymous people ... upload images that can be immediately run... but without a proper chain-of-custody, QA or assurance that an image hasn't been manipulated How is this github any different?
    - hi56793 7y ago
      Many package managers that support git as source allow to pin to a specific commit sha. That's as far as I can see a quite secure way to keep using an uncompromised/verified version. It's not the most popular feature but people do it every now and then, probably it should be done more. I wonder if docker allows this and on the other hand if that's even feasible for say application images, given that applications must be updated a lot for security reasons. Of course if the Dockerfile's parent reference is not pinned, that does only help to some degree...
      - Polyisoprene 7y ago
        You can pull an image using the sha: docker pull ubuntu@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2
        cyphar 7y ago
        Which effectively nobody does. Package managers and distribution packaging systems default to the safe method rather then defaulting to insecure rewritable tags. To be fair, the docker.io/library/* images are signed but no other images are and there are a bunch of issues with how the signing policies work for users that want to enforce that some images must be signed.
        dlitz 7y ago
        The important thing is that tags are signed and up-to-date, like how git tags work or how Debian signs its entire repository as a unit (via the Release file) rather than having developers just sign individual packages. Otherwise, even if it's signed, it's subject to downgrade attacks. Installing known-vulnerable old versions of legitimate software can be just as bad as installing custom malware.
        cyphar 7y ago
        Sure, that's how almost all package managers work. I can't think of a modern package manager from an "enterprise" distribution that didn't have a lot of the features of TUF[+]. And as I said, only official-library Docker images are signed. All other images are unsigned and even for third-party repos you can't force Docker to verify all images from a given repo (you have to enable it globally, which breaks the utility of a local "docker build"). [+] Arch is the only counterexample I can think of and I'm not even sure if my memory is correct.
- filleduchaos 7y ago
  Libraries off Github literally have the source available for you and the community at large to vet. And you'll find almost no sane shop on the planet where people are allowed, hell encouraged to use shady distros or install random utility tools in production the way they are encouraged to pull unchecked binary blobs from Docker Hub in an often non-reproducible manner.
  - speedplane 7y ago
    > Libraries off Github literally have the source available for you and the community at large to vet. If Github was compromised, it would be easy and obvious to insert malicious code in a repository, but hide those changes from anyone on the github website.
    - filleduchaos 7y ago
      Which you can avoid by forking the mainline repo and depending on your fork. Images on Docker Hub don't even need to share their Dockerfile, to talk of all the source/etc that went into their build.
      - speedplane 7y ago
        >> If Github was compromised, it would be easy and obvious to insert malicious code in a repository > Which you can avoid by forking the mainline repo and depending on your fork. If github was compromised, the it would be pretty easy to generate forks with the same compromised code.
  - hk__2 7y ago
    > Libraries off Github literally have the source available for you and the community at large to vet. Nobody read the source code for this exact reason: “the community is here to read it so I won’t".
    - fock 7y ago
      Well, for most libraries used in Desktop Linux, a significant number of stakeholders (developers+users) exist, which actually care for development and the complete thing itself. Also the libraries generally are designed for solving problems and not getting github-stars by bots/dependency-building. For docker (and npm for all that matters) _a lot_ of important dependencies are basically simple one-off "developments" with a single developer and no userbase at all caring for them, because they don't really solve any consistent problem, being basically just created to increase the visibility of its creator on primitive metrics. The community is there for high-level packages, but the dependencies lurk in test-scripts and seldom-used functions carefully placed by some idiotic digital nomads for their personal CV-polishment (ehm, not looking at you: https://github.com/sindresorhus/shebang-regex https://github.com/sindresorhus/shebang-regex). Have a look at where this package is used (basically only in cross-spawn, where there are 10 other similar dependencies), then think about, how much effort creating the dependency hierarchy was, then look up who contributed the changes, where this micro-package was required and finally decide whether this was some thing sane people would do or if it's just for personal gain...
- eeZah7Ux 7y ago
  > How is this issue specific to Docker? Anyone can download a random library off github, use a shady linux distribution Strawman. Anyone can use Debian Stable or at least Testing.
Proven 7y ago
So what if it's centralized? Most enterprise apps are centralized and people can get checksums (not to mention that many are signed) And there's Docker Notary.
Boulth 7y ago
> It's centralized Actually only short names go to docker hub, one can setup their own registry and use it via dns names. Example: docker pull quay.io/letsencrypt/letsencrypt
- jvdongen 7y ago
  Exactly this. For the docker images we use in production, we fork the corresponding git repo, build our own image and push it to our own local docker registry and pull it from there. It's fairly easy to setup in fact.
  - Boulth 7y ago
    Out of curiosity do you resolve it so that the image is FROM scratch or do you rely on alpine/some other base image?
    - kobalsky 7y ago
      I forked an ubuntu image and then used it as a base for all my projects. It doesn't come for free though, you will need to periodically run security updates and then rebuild all images that depend on it.
dehrmann 7y ago
Not docker, but library hosting, in general. My company maintains client libraries for 6 languages, also hosted in the popular place for that language. The standards for account management and authenticating the libraries are all different. Some have scary-little security, some have painful security.
- ahmedalsudani 7y ago
  Agreed 100%. It's insane the practices that fly in our industry. It's as if we didn't know any better. One day, there's going to be a colossal compromise, and that might finally change where we place security in the priority chain.

speedplane 7y ago

> Docker is an invitation to trouble. Anybody can publish a binary blob, and users are expected to blindly trust it How is this issue specific to Docker? Anyone can download a random library off github, use a shady linux distribution, or install utility tools loaded with spyware. I don't think Docker aims to solve issues relating to trusting upstream software. It's a tool to help package applications, just like how tar allows you to package files. What you put in it is up to you.

bayareanative 7y ago
That's a strawman because the shriekingly-obvious difference is ease of facilitation. With Docker, it's a mere couple of commands to pull a box and run it. Docker weakens trust because it lets anonymous people, as well as trusted ones, upload images that can be immediately run... but without a proper chain-of-custody, QA or assurance that an image hasn't been manipulated on Docker's side. It's spray-and-pray DevOps. Image integrity has to be solved on Docker's side with end-to-end integrity or it's all for naught... this is something that cannot be solved within a container or separate from Docker, it must be universal, mandatory and trustworthy.
- speedplane 7y ago
  > Docker weakens trust because it lets anonymous people ... upload images that can be immediately run... but without a proper chain-of-custody, QA or assurance that an image hasn't been manipulated How is this github any different?
  - hi56793 7y ago
    Many package managers that support git as source allow to pin to a specific commit sha. That's as far as I can see a quite secure way to keep using an uncompromised/verified version. It's not the most popular feature but people do it every now and then, probably it should be done more. I wonder if docker allows this and on the other hand if that's even feasible for say application images, given that applications must be updated a lot for security reasons. Of course if the Dockerfile's parent reference is not pinned, that does only help to some degree...
    - Polyisoprene 7y ago
      You can pull an image using the sha: docker pull ubuntu@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2
      - cyphar 7y ago
        Which effectively nobody does. Package managers and distribution packaging systems default to the safe method rather then defaulting to insecure rewritable tags. To be fair, the docker.io/library/* images are signed but no other images are and there are a bunch of issues with how the signing policies work for users that want to enforce that some images must be signed.
        dlitz 7y ago
        The important thing is that tags are signed and up-to-date, like how git tags work or how Debian signs its entire repository as a unit (via the Release file) rather than having developers just sign individual packages. Otherwise, even if it's signed, it's subject to downgrade attacks. Installing known-vulnerable old versions of legitimate software can be just as bad as installing custom malware.
        cyphar 7y ago
        Sure, that's how almost all package managers work. I can't think of a modern package manager from an "enterprise" distribution that didn't have a lot of the features of TUF[+]. And as I said, only official-library Docker images are signed. All other images are unsigned and even for third-party repos you can't force Docker to verify all images from a given repo (you have to enable it globally, which breaks the utility of a local "docker build"). [+] Arch is the only counterexample I can think of and I'm not even sure if my memory is correct.
filleduchaos 7y ago
Libraries off Github literally have the source available for you and the community at large to vet. And you'll find almost no sane shop on the planet where people are allowed, hell encouraged to use shady distros or install random utility tools in production the way they are encouraged to pull unchecked binary blobs from Docker Hub in an often non-reproducible manner.
- speedplane 7y ago
  > Libraries off Github literally have the source available for you and the community at large to vet. If Github was compromised, it would be easy and obvious to insert malicious code in a repository, but hide those changes from anyone on the github website.
  - filleduchaos 7y ago
    Which you can avoid by forking the mainline repo and depending on your fork. Images on Docker Hub don't even need to share their Dockerfile, to talk of all the source/etc that went into their build.
    - speedplane 7y ago
      >> If Github was compromised, it would be easy and obvious to insert malicious code in a repository > Which you can avoid by forking the mainline repo and depending on your fork. If github was compromised, the it would be pretty easy to generate forks with the same compromised code.
- hk__2 7y ago
  > Libraries off Github literally have the source available for you and the community at large to vet. Nobody read the source code for this exact reason: “the community is here to read it so I won’t".
  - fock 7y ago
    Well, for most libraries used in Desktop Linux, a significant number of stakeholders (developers+users) exist, which actually care for development and the complete thing itself. Also the libraries generally are designed for solving problems and not getting github-stars by bots/dependency-building. For docker (and npm for all that matters) _a lot_ of important dependencies are basically simple one-off "developments" with a single developer and no userbase at all caring for them, because they don't really solve any consistent problem, being basically just created to increase the visibility of its creator on primitive metrics. The community is there for high-level packages, but the dependencies lurk in test-scripts and seldom-used functions carefully placed by some idiotic digital nomads for their personal CV-polishment (ehm, not looking at you: https://github.com/sindresorhus/shebang-regex https://github.com/sindresorhus/shebang-regex). Have a look at where this package is used (basically only in cross-spawn, where there are 10 other similar dependencies), then think about, how much effort creating the dependency hierarchy was, then look up who contributed the changes, where this micro-package was required and finally decide whether this was some thing sane people would do or if it's just for personal gain...
eeZah7Ux 7y ago
> How is this issue specific to Docker? Anyone can download a random library off github, use a shady linux distribution Strawman. Anyone can use Debian Stable or at least Testing.

Proven 7y ago

So what if it's centralized? Most enterprise apps are centralized and people can get checksums (not to mention that many are signed) And there's Docker Notary.

Boulth 7y ago

> It's centralized Actually only short names go to docker hub, one can setup their own registry and use it via dns names. Example: docker pull quay.io/letsencrypt/letsencrypt

jvdongen 7y ago
Exactly this. For the docker images we use in production, we fork the corresponding git repo, build our own image and push it to our own local docker registry and pull it from there. It's fairly easy to setup in fact.
- Boulth 7y ago
  Out of curiosity do you resolve it so that the image is FROM scratch or do you rely on alpine/some other base image?
  - kobalsky 7y ago
    I forked an ubuntu image and then used it as a base for all my projects. It doesn't come for free though, you will need to periodically run security updates and then rebuild all images that depend on it.

dehrmann 7y ago

Not docker, but library hosting, in general. My company maintains client libraries for 6 languages, also hosted in the popular place for that language. The standards for account management and authenticating the libraries are all different. Some have scary-little security, some have painful security.

ahmedalsudani 7y ago
Agreed 100%. It's insane the practices that fly in our industry. It's as if we didn't know any better. One day, there's going to be a colossal compromise, and that might finally change where we place security in the priority chain.