<p>This capability is part of what makes Docker Hub great.</p>

<p>Imagine you have a project that requires a very specific system configuration.  For example, you want to use a database, but have a specific configuration for it.  Docker Hub will allow you to pull the official image (e.g. MySQL), make your changes (e.g., change the default location the database runs, add scheduled tasks), and push your new image.  In this example I can now use my custom image as a base for my development and I do not have to script or manually run these configurations every time I pull.</p>

<p>There are security issues as you have now diverge from the official image.  Future updates to the official image will not be updated unless you rebuild with the new official image and push.</p>

<p>Additionally, you are correct in that Docker Hub is somewhat opaque in how these images are generated.  Using my above example I could easily decide I want to switch to MariaDB as my base image, and push to something that makes people thing it is MySQL due to the <a href="https://docs.docker.com/engine/reference/commandline/tag/" rel="nofollow noreferrer">tag</a>.  Because of this, I prefer to start with official images whenever possible.</p>

CC BY-SA 4.0
2019-10-21T17:43:58.373Z
+1 thanks @Wesley Rolnick, like Richard Slater, you offer both pros and cons of Docker hub unofficial images. A good read from you, as you champion the convenience concept of Docker hub hosting unofficial images, alongside official ones and then are critical of that championing by outlining the pitfalls in terms of security. Thank you.
therobyouknow
CC BY-SA 4.0
2019-10-25T19:14:20.130Z
Regarding the tag, why is the default tag called `latest` and not `default`? Latest in itself is also a bit misleading, as an image with no tag specified does not have to reflect that it is the latest image (or inherits from a "latest" image) at all.
Paul-Beyond
CC BY-SA 4.0
2019-10-28T17:09:33.883Z
@PdC: Could you open this as a question so that others have an opportunity to answer?
Wesley Rolnick
CC BY-SA 4.0
2019-10-21T15:48:32.187Z
2019-10-21T15:48:32.187Z
Wesley Rolnick
<p>As with most elements of Information Security, there is a balancing act between usability and security; an increase in usability often results in a correlated decrease in security and visa versa.</p>

<p>As a thought experiment...</p>

<blockquote>
  <p>I can make any server 100% secure by wiping the hard drives, putting it through a shredder and then melting down all of the components parts.  It also makes it 0% usable.</p>
</blockquote>

<p>Docker Hub is no different, the desire is to make these images accessible for the common good, at the cost of traceability and provenance of the images.  Fortunately, there are several tools such as <a href="https://jfrog.com/artifactory/" rel="noreferrer">JFrog Artifactory</a> and <a href="https://www.sonatype.com/product-nexus-lifecycle?" rel="noreferrer">Sonatype Nexus Lifecycle</a> which enable you to apply governance to any Open Source repository (i.e. Docker Hub, Nuget, NPM, etc).</p>

<p>One aspect that I think Docker Hub gets wrong, that other sites get right, namely NPM, is presenting clear information about what Source Repository an image is generated from, that I suspect is due to the decoupled nature of Docker Images from the source code that generates them.</p>

CC BY-SA 4.0
2019-10-21T15:17:57.160Z
+1 upvote thank you (again) Richard Slater. "One aspect that I think Docker Hub gets wrong, that other sites get right, namely NPM, is presenting clear information about what Source Repository an image is generated from, that I suspect is due to the decoupled nature of Docker Images from the source code that generates them." - astute observation. Do you think that indirect derivation in Docker is by design or an oversight? In addition to your tool links mentioned, there are reverse engineering tools here, too: https://stackoverflow.com/questions/48228275/docker-reverse-engineering-of-an-image
therobyouknow
CC BY-SA 4.0
2019-10-21T15:20:22.123Z
I think it's probably a factor of a npm package is in general **exactly** what is in the GitHub repository that it is based upon.  Whereas a Dockerfile routinely collects software from elsewhere in the internet to build the image, either via `FROM` statements or through `apt-get` statements within the Dockerfile.
Richard Slater
CC BY-SA 4.0
2019-10-21T17:46:50.333Z
Both answers reaffirm my own personal policy to always use official images. And if I'm going to publish solutions online for others, I will always base these on the original official images and in doing so provide people with a github repo to download to run my solution out of the box. I'll be part of the solution. Rather than offering people hope of a solution to their issue only for them to find it uses a custom image which is opaque and cumbersome to reverse engineer, though possible. Thank you.
therobyouknow
CC BY-SA 4.0
2020-01-02T11:46:15.913Z
This is why lando.dev is very encouraging - looking at the code - the Dockerfiles are transparent and use the fundamental primitives of the official Dockerfile from hub.docker.com for respective languages that it supports. Also lando.dev is free, fully open source, with no apparent "drug-dealer"/freemium/starter/"community edition" style roadmap to paid versions. And because of that, I'd be willing to donate to it.
therobyouknow
CC BY-SA 4.0
2019-10-21T15:10:46.727Z
2019-10-21T15:10:46.727Z
Richard Slater
<p><strong>Note: also <a href="https://security.stackexchange.com/questions/219924/why-does-docker-hub-allow-non-official-docker-images-and-why-do-they-exist">posted in Security StackExchange</a> as there is a security aspect to this question (sorry for cross-posting).</strong></p>

<p>I'm evaluating Docker images for my development and production setups.</p>

<p>When I research how to do something in Docker, quite often I find answers that include the author's own Docker image. For me, this is not suitable as this hinders the transparency of the solution and uncertainty of reliance on future maintenance by that author. Both of these potential issues have security implications.</p>

<p>While the <a href="https://hub.docker.com/" rel="noreferrer">Docker Hub</a>, can provide a convenient centralised and well-known outlet for publishing one's own Docker images, derived from officials, what would be the advantage of using these unofficial images over the originals.</p>

<p>I am aware of reverse engineering tools, as described in answers on <a href="https://stackoverflow.com/questions/48228275/docker-reverse-engineering-of-an-image">Stack Overflow</a> and that at least some of the unofficial Docker images have an associated GitHub repo that apparently shows how the Docker image was built. But this is an inconvenient level of "indirection" or friction to being really sure (if at all possible) as to the contents of the Docker image.</p>

<docker>
Why does Docker hub allow non-official Docker images and why do they exist?
therobyouknow
# Why does Docker hub allow non-official Docker images and why do they exist?

(Asked by: username_0 on 2019-10-21)

**Note: also [posted in Security StackExchange](https://security.stackexchange.com/questions/219924/why-does-docker-hub-allow-non-official-docker-images-and-why-do-they-exist) as there is a security aspect to this question (sorry for cross-posting).**

I'm evaluating Docker images for my development and production setups.

When I research how to do something in Docker, quite often I find answers that include the author's own Docker image. For me, this is not suitable as this hinders the transparency of the solution and uncertainty of reliance on future maintenance by that author. Both of these potential issues have security implications.

While the [Docker Hub](https://hub.docker.com/), can provide a convenient centralised and well-known outlet for publishing one's own Docker images, derived from officials, what would be the advantage of using these unofficial images over the originals.

I am aware of reverse engineering tools, as described in answers on [Stack Overflow](https://stackoverflow.com/questions/48228275/docker-reverse-engineering-of-an-image) and that at least some of the unofficial Docker images have an associated GitHub repo that apparently shows how the Docker image was built. But this is an inconvenient level of "indirection" or friction to being really sure (if at all possible) as to the contents of the Docker image.

**Tags:** docker


---

## 2 answers

### Answer by username_3 on 2019-10-21. Score: 6 | Accepted answer

As with most elements of Information Security, there is a balancing act between usability and security; an increase in usability often results in a correlated decrease in security and visa versa.

As a thought experiment...

> I can make any server 100% secure by wiping the hard drives, putting it through a shredder and then melting down all of the components parts. It also makes it 0% usable.

Docker Hub is no different, the desire is to make these images accessible for the common good, at the cost of traceability and provenance of the images. Fortunately, there are several tools such as [JFrog Artifactory](https://jfrog.com/artifactory/) and [Sonatype Nexus Lifecycle](https://www.sonatype.com/product-nexus-lifecycle?) which enable you to apply governance to any Open Source repository (i.e. Docker Hub, Nuget, NPM, etc).

One aspect that I think Docker Hub gets wrong, that other sites get right, namely NPM, is presenting clear information about what Source Repository an image is generated from, that I suspect is due to the decoupled nature of Docker Images from the source code that generates them.

> **Comments:**
> **username_0**: +1 upvote thank you (again) username_3. "One aspect that I think Docker Hub gets wrong, that other sites get right, namely NPM, is presenting clear information about what Source Repository an image is generated from, that I suspect is due to the decoupled nature of Docker Images from the source code that generates them." - astute observation. Do you think that indirect derivation in Docker is by design or an oversight? In addition to your tool links mentioned, there are reverse engineering tools here, too: https://stackoverflow.com/questions/48228275/docker-reverse-engineering-of-an-image  
> **username_3**: I think it's probably a factor of a npm package is in general **exactly** what is in the GitHub repository that it is based upon.  Whereas a Dockerfile routinely collects software from elsewhere in the internet to build the image, either via `FROM` statements or through `apt-get` statements within the Dockerfile.  
> **username_0**: Both answers reaffirm my own personal policy to always use official images. And if I'm going to publish solutions online for others, I will always base these on the original official images and in doing so provide people with a github repo to download to run my solution out of the box. I'll be part of the solution. Rather than offering people hope of a solution to their issue only for them to find it uses a custom image which is opaque and cumbersome to reverse engineer, though possible. Thank you.  
> **username_0**: This is why lando.dev is very encouraging - looking at the code - the Dockerfiles are transparent and use the fundamental primitives of the official Dockerfile from hub.docker.com for respective languages that it supports. Also lando.dev is free, fully open source, with no apparent "drug-dealer"/freemium/starter/"community edition" style roadmap to paid versions. And because of that, I'd be willing to donate to it.  

---

### Answer by username_1 on 2019-10-21. Score: 4

This capability is part of what makes Docker Hub great.

Imagine you have a project that requires a very specific system configuration. For example, you want to use a database, but have a specific configuration for it. Docker Hub will allow you to pull the official image (e.g. MySQL), make your changes (e.g., change the default location the database runs, add scheduled tasks), and push your new image. In this example I can now use my custom image as a base for my development and I do not have to script or manually run these configurations every time I pull.

There are security issues as you have now diverge from the official image. Future updates to the official image will not be updated unless you rebuild with the new official image and push.

Additionally, you are correct in that Docker Hub is somewhat opaque in how these images are generated. Using my above example I could easily decide I want to switch to MariaDB as my base image, and push to something that makes people thing it is MySQL due to the [tag](https://docs.docker.com/engine/reference/commandline/tag/). Because of this, I prefer to start with official images whenever possible.

> **Comments:**
> **username_0**: +1 thanks @username_1, like username_3, you offer both pros and cons of Docker hub unofficial images. A good read from you, as you champion the convenience concept of Docker hub hosting unofficial images, alongside official ones and then are critical of that championing by outlining the pitfalls in terms of security. Thank you.  
> **username_2**: Regarding the tag, why is the default tag called `latest` and not `default`? Latest in itself is also a bit misleading, as an image with no tag specified does not have to reflect that it is the latest image (or inherits from a "latest" image) at all.  
> **username_1**: @PdC: Could you open this as a question so that others have an opportunity to answer?  

---

