From 2456150a5266fea71b050487a953c39358ddd585 Mon Sep 17 00:00:00 2001
From: Tonis Tiigi <tonistiigi@gmail.com>
Date: Mon, 18 Jul 2016 19:12:54 -0700
Subject: [PATCH] Update docker load security docs

Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
(cherry picked from commit f17469e890c1fd2ea9d63e7bfe1025df9754c97b)
Signed-off-by: Tibor Vass <tibor@docker.com>
---
 docs/security/security.md | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/docs/security/security.md b/docs/security/security.md
index 17810eecc9..44853c22bb 100644
--- a/docs/security/security.md
+++ b/docs/security/security.md
@@ -120,13 +120,11 @@ certificates](https.md).
 
 The daemon is also potentially vulnerable to other inputs, such as image
 loading from either disk with 'docker load', or from the network with
-'docker pull'. This has been a focus of improvement in the community,
-especially for 'pull' security. While these overlap, it should be noted
-that 'docker load' is a mechanism for backup and restore and is not
-currently considered a secure mechanism for loading images. As of
-Docker 1.3.2, images are now extracted in a chrooted subprocess on
-Linux/Unix platforms, being the first-step in a wider effort toward
-privilege separation.
+'docker pull'. As of Docker 1.3.2, images are now extracted in a chrooted 
+subprocess on Linux/Unix platforms, being the first-step in a wider effort 
+toward privilege separation. As of Docker 1.10.0, all images are stored and 
+accessed by the cryptographic checksums of their contents, limiting the 
+possibility of an attacker causing a collision with an existing image.
 
 Eventually, it is expected that the Docker daemon will run restricted
 privileges, delegating operations well-audited sub-processes,