On Sat, 2 May 2020 at 06:24, Micah Anderson <mi...@debian.org> wrote: > I'm not sure that this is the right place to file this issue, but I was unable > to find a better place. Feel free to redirect to a more suitable place. I > talked > to the debian-cloud people and they didn't think that this was their purview.
I think an issue under [1] would probably be more correct, but this will do (I'm not at all fond of the Debian BTS, as I always have to look up the documentation for how to do simple things like close bugs and even then I typically get something wrong, but such is life). [1]: https://github.com/debuerreotype/docker-debian-artifacts > I really value the debian built docker images that are available at Docker > Hub. The fact that they are built in a reproducible fashion, and are available > as "official" docker images (which means that they are verifiable through > Docker > Content Trust (DCT) signatures) goes a long way for reducing my paranoia. The reproducible part here is true, but my added caveat would be that you should probably not place *too* much faith in DCT. What it verifies and what something like a detached PGP signature verify are *very* different things (it's solving a different problem); the DCT verification is verification of namespace control more than contents. Additionally (and probably more critically, depending on how much stock you put in DCT), the signatures on the Docker official images program at large have been nonfunctional[2][3][4] for quite some time now, so anyone using them will likely be silently getting outdated images (which is an absolutely horrifying failure mode in itself, IMO). [2]: https://github.com/docker-library/official-images/issues/6838 [3]: https://github.com/docker-library/official-images/issues/5874 [4]: https://github.com/docker-library/official-images/issues/1516 > The reason I'm writing is because I'd like to have the option of obtaining > these > images from Debian directly, from a Debian controlled registry that is > properly > notarized to provide the same cryptographically verifiable trust chain as is > provided through Docker Hub. > > Being able to verify the images from the same root of trust that the operating > system depends on, would be a nice improvement. Considering that the images > are > essentially building Debian, on Debian, it would be nice to not have to rely > on > docker.io to trust the resulting images. Sure, they are signed, but the trust > root itself is not coming from Debian itself. When I `debootstrap` from a > debian > system, by default, it already verifies the packages pulled automatically, > from > the same root of trust that the OS depends on. This would definitely be very nice; unfortunately, the container ecosystem at large is very resistant to anything PGP-related, so I don't think we'll see PGP signatures on container images being supported any time soon. However, there is some collaboration in-progress on what's being called "Notary v2" [5], which is a re-imagining of what "container image signing" means such that many more use cases than were solved in v1 are being considered, and I think this is our best bet for being able to have something like a trust root distributed as a Debian package which can then be used to verify downloaded images. Anyone who is interested in more information on that initiative or especially in collaborating with those folks should check out [6]. [5]: https://www.docker.com/blog/community-collaboration-on-notary-v2/ [6]: https://github.com/notaryproject/requirements > It would be nice to get my debian docker images from a debian registry, and > not > have to trust Docker Hub as a secondary verifier. > > ... > > Maybe a good starting point would be to provide a simple registry service at > https://docker.debian.net, where you can already find the image checksums. It > doesn't have to be a notarized one from the beginning, but just a registry > where > the same images that are pushed to Docker Hub are also pushed. Perhaps using > the > built-in registry at Salsa would be another option. > > Once things are reliably being pushed to a registry on debian.net, or salsa, > then building the notarization pieces for verification would be next. > > Once that has been completed, then perhaps this can become a proper Debian > service. Right now, "docker.debian.net" is unfortunately just a simple static Jekyll website, so adding a registry there is kind of a large undertaking (and I definitely don't have the resources to set something like that up). Using the registry built in to Salsa is an option, although in my experience the GitLab registry is extremely basic. However, setting up automation for pushing that is not something I currently have the resources to do (since it's not something I would personally use, I can't justify using any of my existing available resources to do so, especially in a way that will still support all the many architectures that are currently published to https://hub.docker.com/_/debian). Additionally, I think that would be something we would want to have a larger discussion with the Salsa admins about to make sure they'd be OK with the potentially added load of both the storage and bandwidth. On the point of serving a registry from a static site, I seem to recall that there have been some discussions in the OCI around adjusting the distribution specification to allow for a fully-static registry (since the current specification requires additional headers that make something fully-static difficult), but I don't recall where those ended up (likely that the entire idea is deferred for discussion until v1.0 of that specification actually reaches an official GA status). ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4
