喷一喷Docker Hub的改版

大家都知道，我是基于Docker的开源项目Vulhub的维护者，所以对Docker相关的一举一动尤为关注。

前段时间收到来自Docker官方的一封邮件，当时我一看顿时蒙了，还以为收到了假的邮件：

解释一下具体的意思：Docker官方仓库Docker Hub修改了用户协议（Terms of Service），从9月1日开始，免费的账户将受到如下限制：

• 如果你的镜像在6个月内没有pull或者push，将会被标记为“不活跃的”，并被删除
• 不活跃的旧tag也会受到影响：比如某个镜像的最新tag :latest在6个月内活跃过，它将不被删除；但是这个镜像的旧tag :old-version如果没有活跃，仍然会被删除
• 付费用户的镜像不受影响
• 官方镜像不受影响（命名空间为library）
• 免费用户上传的同一镜像，6个小时内最多被同一个用户（IP地址）拉取200次

详细的FAQ，可以在这个地址查看：https://www.docker.com/pricing/resource-consumption-updates

Docker官方的这一系列新规，无疑可以为自己节省大笔的投入，但对于像我这样的用户来说，简直就是一个噩耗。在Twitter上吐槽了一下，也收到了来自大洋彼岸的赞同：

这一改版对大部分用户来说可能影响不是非常大，但对于安全研究人员来说无疑是一个噩耗，为什么？

Docker，以及一批基于Docker的开源漏洞复现平台（Vulhub），帮助大量的安全初学者解决了最为头疼的问题：如何找到存在漏洞的环境。

在此之前，大家如果想学习一个3年以前的漏洞，可能会选择下面这些方式：

• 在fofa、shodan、zoomeye上搜索互联网案例，运气好能找到一些一直没有修复的网站
• 下载源码，并学习一堆编译工具和版本管理工具，耗费巨大的时间在本地搭建一个存在漏洞的环境

前者无疑是存在法律风险的，而且时间稍久的漏洞其实就很难在互联网上找到案例了；后者对于初学者来说，是一个耗时耗力的大工程，所以才有了朋友圈流传的那句话：漏洞复现5分钟，环境搭建2小时。

Vulhub的出现及时弥补了这个问题，所有的漏洞环境只需要执行一条docker-compose命令即可一键启动。

这个看似简单的过程其实就高度依赖于Docker Hub：虽然所有的漏洞环境Dockerfile源码存放在Github中，但是使用者并不需要自己编译这个Dockerfile，而是直接拉取镜像即可使用。

为什么会这么设计？其中在Vulhub项目创建之初，所有的Dockerfile镜像是放在漏洞相关的文件夹下的，启动环境时用户会先对Dockerfile进行编译，再启动容器。但是，在运营一段时间后，我发现这样设计存在下面两个问题：

• 编译镜像的过程中，大多数情况下会涉及到下载源码、第三方资源等操作，这个过程及其依赖于用户的网络情况，对于大多数中国大陆用户来讲这个过程是不友好的，速度极慢而且容易失败
• 镜像编译的过程有很多不稳定因素，某一个依赖小版本的更新都可能导致编译失败，也许今天编译成功的镜像一年以后再编译就不会成功了，维护成本较大

所以，我们后来将大部分的Dockerfile从漏洞环境中剥离，存放在根目录下的base/文件夹中，用户仍然可以找到Dockerfile并自行编译。但默认情况下，用户使用时不再需要自己编译镜像，而是从Docker Hub中拉取我们已经编译好的镜像并运行。

回到前文，大家也能理解我吐槽的原因了。Docker Hub的这一政策，很显然可能会导致我存放在官方仓库里的一些镜像失效，进而导致Vulhub的使用者无法正常启动漏洞环境。

当然，在商言商，Docker官方为了节省成本，提升硬盘空间利用率，做出这样的举措也无可厚非。对于Vulhub这个项目来说，我们也有相应的应对之策：

• Vulhub从7月份开始接受了来自于WANGAN.COM的长期赞助，完全可以Cover住Pro账户的成本，在必要的时刻完全可以解决这个问题
• 受到Vissue #198 的启发，Vulhub已经开始进行历史Dockerfile的整理与重测试，我们会使用Github Action提供的能力，定期对所有Dockerfile进行编译测试。如果发现编译不通过的镜像进行及时修复。这个举措也能保证，即使Docker官方将我们的镜像删除了，用户也可以自己编译新的镜像
• 后续我也会借助Github Action提供的能力，定期对Vulhub设计的所有镜像进行Pull，避免其进入inactive状态

所以大家也不必担心Vulhub以后的正常使用，3年多来我们一直是一个活跃的项目，以后也一样。

相比起来，下面这些情况可能会更让我担心：

• 一些项目的旧版本
• 一些有研究价值，但不再更新的项目

举个例子，6个月后，我们可能将无法下载jenkins/jenkins:2.138-slim，这是CVE-2018-1000861的受影响版本。为什么呢？jenkins原本是一个Docker官方镜像，但后来被Jenkins自己接管了，那么如果Jenkins不是付费用户，它的老版本镜像将会受到新的TOS的影响。

这才是我最担心的事，我们很可能以后很难再在Docker上找到一些老版本的镜像了。多多动手，也不是件坏事，暂且这么安慰自己吧！

喜欢这篇文章吗，关注我，点个在看再走吧~