-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, 28 Oct 2013 09:48:52 +0000 "Richard W.M. Jones" rjones@redhat.com wrote:
[NB: CC'd to the Fedora cloud SIG mailing list]
On Tue, Oct 01, 2013 at 09:22:44AM -0400, Matthew Miller wrote:
On Tue, Oct 01, 2013 at 02:20:11PM +0100, Richard W.M. Jones wrote:
Is there a reason to not use the official Fedora cloud images?
That's part 2 of this exercise. Would like to talk to you about that separately at some point.
Okay. Any time. :)
So there are a few immediate problems (some of them in virt-builder itself).
(1) Virt-builder really needs to be able to source images from multiple places. At the moment there is only one source location allowed, unless the user clumsily uses the --source option to point at another one.
(2) Virt-builder currently assumes the image format is xz-compressed. Actually I notice the raw.xz images are in the correct format already, so we're good here.
:) glad that its right
(3) Virt-builder requires all images to be GPG-signed. It worries me that these images are neither signed nor downloaded over https.
most if not all mirrors don't run https on the mirrors, http://dl.fedoraproject.org/pub/fedora/linux/releases/test/20-Alpha/Images/x... we do gpg sign the CHECKSUMS for actual releases. What other signing are you thinking of?
(4) Virt-builder requires a (signed) index file describing each cloud image. I believe it would be a good thing for the cloud images to include an index file, so that tools can automatically find out what's there. The format of the index file is described here:
http://libguestfs.org/virt-builder.1.html#creating-and-signing-the-index-fil...
However having the index file will be less useful until (1) is fixed.
We would need a way to make the index file that's integrated into the release process.
(5) Digital signatures: Currently virt-builder requires all indexes and images to be signed by yours truly unless you go through an involved process described here:
http://libguestfs.org/virt-builder.1.html#setting-up-a-gpg-key
We need to fix this, but key management is a non-trivial problem, since we cannot host the public key in the same place as the index & images (an attacker could replace both the images & key at the same time). What's the strategy going to be for signing these cloud images?
anything we would sign in fedora would be signed with the release key that is changed every release.
none of these problems are things that can't be fixed.
Dennis