3 ms·

The hardest part of that would be verifying image authenticity. Google Cloud uses an adjacent feature called binary authorization. When turned on, only images

The hardest part of that would be verifying image authenticity. Google Cloud uses an adjacent feature called binary authorization. When turned on, only images that are signed by a given authority (usually your ci/cd instruments) can be run inside your Kubernetes cluster. Binary authorization may be a good starting point for someone trying to make bittorrent distributed images a usable thing.

sneak 6y ago
> The hardest part of that would be verifying image authenticity. That's exactly what Bittorrent does with its hash tree. You'd get the root hash (extremely tiny) from Docker Hub, and the rest of the metadata, as well as the data blocks, from the swarm. The authenticity is all handled by the TLS that serves you the root infohash from Docker Hub. It's a Merkle tree: the root hash is for the metadata, which is a list of hashes of the blocks.
- im3w1l 6y ago
  If this reads like greek, let me dumb it down. You get the hash of the final result from the trusted server and hash is checked. Because of this you will never get an invalid image. There are also some clever tricks to make sure no one can force you to start over from scratch by sending wrong data. But that's more of a detail.
pixl97 6y ago
Why, the website could still have the hash for the image which is only a few KB versus hundreds of megabytes or even gigabytes. Just have the bit-docker app check the hash before executing.
jtsiskin 6y ago
What is the issue here? Is the torrent checksum (provided by docker) not enough?
- bsamuels 6y ago
  Let's say someone hacks a maintainer for the Ubuntu base image. The hacker publishes a new version of the base image with a backdoor. When the backdoor is detected, you now need a revocation system so the distribution of the malicious image will die. You can theoretically do this on the tracker level, but people may build other trackers that may not propagate the changes.
  - lights0123 6y ago
    You still would have a centralized manifest system though, right? It shouldn't hurt Docker much at all to host a few KBs of data describing the hash of each layer, which is still fetched every time, just big downloads are done over torrents.

sneak 6y ago

> The hardest part of that would be verifying image authenticity. That's exactly what Bittorrent does with its hash tree. You'd get the root hash (extremely tiny) from Docker Hub, and the rest of the metadata, as well as the data blocks, from the swarm. The authenticity is all handled by the TLS that serves you the root infohash from Docker Hub. It's a Merkle tree: the root hash is for the metadata, which is a list of hashes of the blocks.

im3w1l 6y ago
If this reads like greek, let me dumb it down. You get the hash of the final result from the trusted server and hash is checked. Because of this you will never get an invalid image. There are also some clever tricks to make sure no one can force you to start over from scratch by sending wrong data. But that's more of a detail.

pixl97 6y ago

Why, the website could still have the hash for the image which is only a few KB versus hundreds of megabytes or even gigabytes. Just have the bit-docker app check the hash before executing.

jtsiskin 6y ago

What is the issue here? Is the torrent checksum (provided by docker) not enough?

bsamuels 6y ago
Let's say someone hacks a maintainer for the Ubuntu base image. The hacker publishes a new version of the base image with a backdoor. When the backdoor is detected, you now need a revocation system so the distribution of the malicious image will die. You can theoretically do this on the tracker level, but people may build other trackers that may not propagate the changes.
- lights0123 6y ago
  You still would have a centralized manifest system though, right? It shouldn't hurt Docker much at all to host a few KBs of data describing the hash of each layer, which is still fetched every time, just big downloads are done over torrents.