On Mon, Oct 28, 2013 at 08:17:28AM -0500, Dennis Gilmore wrote: > On Mon, 28 Oct 2013 09:48:52 +0000 > "Richard W.M. Jones" <rjones@xxxxxxxxxx> wrote: > > (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/x86_64/Fedora-Images-x86_64-20-Alpha-CHECKSUM > we do gpg sign the CHECKSUMS for actual releases. What other signing > are you thinking of? Ah, didn't spot that signature. Virt-builder currently requires that the images are signed, although signing the checksums (provided they are strong, which in this case they are) is sufficient. I should put the checksums into the index file, which (itself being signed) means the file signatures would no longer be needed. One way to look at this would be the CHECKSUMS file grows to become an index / metadata file. > > (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-file > > > > 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. I think having metadata is a good idea. At the very least it allows you to have a tool where you can list available images, their sizes, locations and notes. The virt-builder index ties in with libosinfo as well, allowing a tool to download cloud images, consult the libosinfo database, and present the guests with the right amount of RAM, correct virtual devices and so on. > > (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. $ gpg --verify Fedora-Images-x86_64-20-Alpha-CHECKSUM gpg: Signature made Sat 21 Sep 2013 05:48:13 BST using RSA key ID 246110C1 gpg: Good signature from "Fedora (20) <fedora@xxxxxxxxxxxxxxxxx>" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: C7C9 A9C8 9153 F201 83CE 7CBA 2EB1 61FA 2461 10C1 However this requires me to manually check the fingerprint against https://fedoraproject.org/keys. (It's correct in this case.) Is there an automated way to do that? > none of these problems are things that can't be fixed. Right. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
