Bug#959446: debuerreotype: Consider additionally providing images on debian infrastructure
Tianon Gravi writes: > On Sat, 2 May 2020 at 06:24, Micah Anderson 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. > > 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 Thanks for these references, I wasn't aware of them. >> 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. What about something far more simple... what if you, when you've built the images, created a detached signature of the image, and published it somewhere. That way it would be trivial for people to take a docker image, look at the hash, combine it with the debian keyring and your signature, and feel reasonably confident in the chain of trust being unbroken. Instead of some hopelessly complicated framework, or adding something to the container image format, just build (automatically), a file containing signatures, that is then signed and published somewhere. > 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 Yesterday and the day before were two sessions on the status of notary v2 at kubecon: https://kccnceu20.sched.com/event/Zewy/notary-v2-introduction-and-status-report-justin-cormack-docker-omar-paul-amazon https://kccnceu20.sched.com/event/Zexw/notary-v2-outstanding-issues-working-session-justin-cormack-docker-steve-lasker-microsoft I feel like the tongue-in-cheek references to Antoni Gaudà and the Sagrada Familia in the slide deck, is very telling. Its fairly obvious that this is something that I can just ignore for another year, and hope it will be in a somewhat usable state next year, maybe However, in the meantime, the supply chain is not authenticated, and I'm afraid the perfect is being the enemy of the good here. -- micah
Bug#959446: debuerreotype: Consider additionally providing images on debian infrastructure
On Sat, 2 May 2020 at 06:24, Micah Anderson 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
Bug#959446: debuerreotype: Consider additionally providing images on debian infrastructure
Package: debuerreotype Version: 0.10-1 Severity: normal Hello! 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 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. I am not writing to suggest any of that change, I think it should definitely stay that way. 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. 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. Understandably, this isn't a trivial effort. It requires a debian provided registry, and a TUF configured notarization process. Each of these is an effort in itself. 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. Thanks for considering this, and thanks for working on these images! micah -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-8-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debuerreotype depends on: ii debian-archive-keyring 2019.1 Versions of packages debuerreotype recommends: pn debootstrap Versions of packages debuerreotype suggests: pn diffoscope
