[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.
(3) Virt-builder requires all images to be GPG-signed. It worries me that these images are neither signed nor downloaded over https.
(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.
(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?
----------------------------------------------------------------------
To test this out, I created an index file for the 64 bit Fedora 19 cloud image, which is attached. I also signed it (signature also attached). You can test this if you want by putting all 3 files into a directory anywhere and using commands such as:
virt-builder --source file:///path/to/index.asc -l
virt-builder --source file:///path/to/index.asc --notes fedora-cloud-19
virt-builder --source file:///path/to/index.asc \ fedora-cloud-19 \ --size 20G \ --root-password password:123456 \ --install @development-tools
And basically it works:
$ virt-builder --source file:///mnt/scratch/index.asc fedora-cloud-19 --size 20G --root-password password:123456 --install @development-tools[ 0.0] Downloading: file:///mnt/scratch/Fedora-x86_64-19-20130627-sda.raw.xz [ 0.0] Creating disk image: fedora-cloud-19.img [ 1.0] Uncompressing: file:///mnt/scratch/Fedora-x86_64-19-20130627-sda.raw.xz [ 14.0] Running virt-resize to expand the disk to 20.0G [ 44.0] Opening the new disk [ 47.0] Setting a random seed [ 47.0] Setting root password [ 47.0] Installing packages: @development-tools [ 156.0] Finishing off Output: fedora-cloud-19.img Total usable space: 19.7G Free space: 18.6G (94%)
I didn't test this one to see if it boots.
Rich.
-----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
On Mon, Oct 28, 2013 at 08:17:28AM -0500, Dennis Gilmore wrote:
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.
+1 -- that would be great. I'd also like to see files in the simplestreams format as used by Ubuntu -- see http://cloud-images.ubuntu.com/releases/streams/v1/ Having it integrated in the process means there's no reason we can't do both.
none of these problems are things that can't be fixed.
:)
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@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/x... 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-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.
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@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.
On Mon, Oct 28, 2013 at 02:29:19PM +0000, Richard W.M. Jones wrote:
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.
One thing I should add: I'm not fussed about the specific format currently used by virt-builder for the index. However whatever format is used would need to contain at least the same information as the virt-builder index, and be signed.
http://libguestfs.org/virt-builder.1.html#creating-and-signing-the-index-fil...
Rich.
On 10/28/2013 03:48 AM, Richard W.M. Jones wrote:
(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?
Hmmm, you do indeed have to be very careful with the private key, but as stated this problem didn't make much sense to me, you host the key on a keyserver and you don't have a replacement problem for /public/ key.
Passing around the private key for doing the signing is certainly a tricky problem.
On Mon, Oct 28, 2013 at 08:31:18AM -0600, Mats Wichmann wrote:
On 10/28/2013 03:48 AM, Richard W.M. Jones wrote:
(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?
Hmmm, you do indeed have to be very careful with the private key, but as stated this problem didn't make much sense to me, you host the key on a keyserver and you don't have a replacement problem for /public/ key.
Passing around the private key for doing the signing is certainly a tricky problem.
The private key is, of course, private. It never leaves my house.
The problem is you need to tell people which key has been used to sign the index (and images -- but see other discussion). If you put the public key, or even just its fingerprint, on the server, then someone who attacks the server can replace both the signed index with one signed by themselves, and replace the fingerprint with their own fingerprint.
The (not great) solution in virt-builder is to compile a fingerprint into the binary. At least this means that an attacker needs to attack both http://libguestfs.org AND the Fedora build system simultaneously.
If we sign cloud images with the Fedora release key, and have a separate channel to distribute those keys (which I guess we do) then I believe everything should be good.
Rich.
On Mon, Oct 28, 2013 at 09:48:52AM +0000, Richard W.M. Jones wrote:
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.
Fixed in 1.25.3 (development version). In Fedora terms this means Fedora 21, but I could backport the upstream patches to Fedora 20 if people are interested in this.
(3) Virt-builder requires all images to be GPG-signed. It worries me that these images are neither signed nor downloaded over https.
The solution to this (further down the thread) was to use checksums in the index file. This is possible in 1.24.1 (stable version, Fedora 20) & 1.25.3.
Rich.
On Fri, Nov 01, 2013 at 08:14:17PM +0000, Richard W.M. Jones wrote:
(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.
Fixed in 1.25.3 (development version). In Fedora terms this means Fedora 21, but I could backport the upstream patches to Fedora 20 if people are interested in this.
Cool. I think that would be nice given that the F21 timeframe is likely to be a bit long.
(3) Virt-builder requires all images to be GPG-signed. It worries me that these images are neither signed nor downloaded over https.
The solution to this (further down the thread) was to use checksums in the index file. This is possible in 1.24.1 (stable version, Fedora 20) & 1.25.3.
So, what else do we need here?
On Fri, Nov 01, 2013 at 04:16:11PM -0400, Matthew Miller wrote:
On Fri, Nov 01, 2013 at 08:14:17PM +0000, Richard W.M. Jones wrote:
(3) Virt-builder requires all images to be GPG-signed. It worries me that these images are neither signed nor downloaded over https.
The solution to this (further down the thread) was to use checksums in the index file. This is possible in 1.24.1 (stable version, Fedora 20) & 1.25.3.
So, what else do we need here?
Well .. easiest is just to make a signed index.asc file and put it next to the *-CHECKSUM file here:
http://www.mirrorservice.org/sites/dl.fedoraproject.org/pub/fedora/linux/rel...
(Actually .. I think it needs to go in the directory *above* so it can cover both the 32- and 64-bit images.)
Here's an example index file: http://libguestfs.org/download/builder/index.asc
Here is the ref documentation for the index file format: http://libguestfs.org/virt-builder.1.html#creating-your-own-templates
I would then add the URL of the index file [mirroring?] to virt-builder, and it all ought to Just Work ...
But also .. you might decide that the index format (which I'll admit to just hacking together over one night) is not right in which case we could use another format. It would, of course, need to cover all the fields that the current index has.
Rich.
On Fri, Nov 01, 2013 at 08:34:50PM +0000, Richard W.M. Jones wrote:
http://www.mirrorservice.org/sites/dl.fedoraproject.org/pub/fedora/linux/rel...
We can't (easily) do this for older releases, since those bits are out the door. But hopefully we can get it there for F20. See https://fedorahosted.org/rel-eng/ticket/5805 and please add anything to it that helps explain what's needed.
I would then add the URL of the index file [mirroring?] to virt-builder, and it all ought to Just Work ...
If you use download.fedoraproject.org URLs, like
http://download.fedoraproject.org/pub/fedora/linux/releases/19/Images/
or
http://download.fedoraproject.org/pub/fedora/linux/releases/20/Images/index....
they're automatically redirected by mirrormanager.
But also .. you might decide that the index format (which I'll admit to just hacking together over one night) is not right in which case we could use another format. It would, of course, need to cover all the fields that the current index has.
It looks fine to me. Nice and simple.
-
Dennis Gilmore -
Mats Wichmann -
Matthew Miller -
Richard W.M. Jones