[Fedora-legal-list] Hosting Fedora cloud images

[Richard W.M. Jones]

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 at redhat.com> 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 at fedoraproject.org>"
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