Hi, Am Dienstag, 20. März 2018, 00:03:20 CET schrieb Aleksa Sarai:
On 2018-03-19, Fabian Vogt <fvogt@suse.com> wrote:
The issue is actually larger than this. The official-library doesn't use the image we create in OBS directly. Rather it takes a tar of the rootfs and then applies them *inside* a Docker build.
Yes, that's part of the "convoluted submission process"...
My point was that the *build and publishing* process was also worryingly convoluted. Submission processes only really affect us, but if the build is convoluted and may break things then it affects users.
The build is part of the submission from my viewpoint. The submission is every step until the image appears at its destination. Especially as the image remains even if the source git repo got deleted.
Because they (still!) use AUFS, this causes the rootfs to not be identical to the one we built (in particular this strips certain xattrs like "security.capability").
Ouch, I did not know that. Does https://github.com/docker-library/official-images/blob/master/library/opensu... ("Constraints: !aufs") not have an effect? I assume it would apply not only to the users but also to the builder itself.
I fear I may be getting a bit old, I completely forgot about this change. :facepalm: On paper that should have fixed the AUFS issue, yes.
However the image builds still do a Docker build which extracts a tar archive. They are somewhat careful about reproducibility, but my experience with it has left me a little jaded (not to mention that it all goes through an entire round-trip inside Docker's tar handling -- which is not using tar-split to ensure layer IDs are consistent).
Yes, I guess to verify the integrity we'd need to download the published image and compare it with the files we pushed. That's not good (i.e. unacceptable).
If it doesn't, it's actually a reason to pull all of the images from the library and not just tumbleweed.
I agree. If we're going to move tumbleweed, I don't see why we wouldn't move all of them.
Tumbleweed as rolling release is an exception - but if you think that leap should be moved as well (it also makes publishing easier), it's probably the best option. Currently there's no built+tested+published Leap 15.0 image, once there is I'll set up a repository. I'll try to add updated images for 42.3 as well.
I don't think it's an issue for the opensuse/ NS on docker hub either, as there we control every bit of the blobs landing on the client and they can verify that by comparing the digest. We'll just have to make the list easy to access and provide a guide for verification.
It's basically identical to the downloading of .iso images from download.opensuse.org - the download itself and the file can be modified, but we provide a checksum for (sadly voluntary) verification. There's a few comments about that in the osc-plugin-factory PR.
The "opensuse/..." namespace is what I meant by "images we built in OBS", because those bits are exact copies of the files we build inside OBS. The official-library makes the files go through a round-trip build before publishing them (breaking the reproducibility).
Yes, they should be - yet can't be 100% certain that they are as we don't have control over the docker hub either. That's why signing or some other way of verification is important to offer.
This is one of the reasons why I set up "opensuse/amd64" once we discovered the above Docker breakage. The main downside with not using official-library is that we cannot sign images in "opensuse/...".
We can sign images in the official-library? Cheers, Fabian -- Fabian Vogt - Release Engineer SUSE Linux GmbH GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org