-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 28 Oct 2013 09:48:52 +0000
"Richard W.M. Jones" <rjones(a)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/Image...
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-...
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJSbmP6AAoJEH7ltONmPFDRB/YQANMgCo4QZf3POAyvopGe/8Us
2DmfYNdW8aoHjy6mn1HdE2hmqJ0q3WptLdDXoowokpI+LWTFXAAv54trSQ9KoZri
rMwMN65EsYpTzOq0AL5bnROds0r9rFYRrJDo41EWkEc1kyOR0KogpeAxZs+tXnnQ
wRK47sM+6A0XGjw4m+/eT8q4dWuBO6JBFTP9X7OsyvnYUeSU8jAzDo8MpgcSc2ar
cfxyC3YEUBQ8+svtLVavLxOf0ZgGDjrSphrD16jgVZv3lD0GXyIBAyQxyUEJZnWN
hF5234a0SV1aIILhkI6Lu+xv7R3SAuLsq8IMtukmCjJFeZjZhhRi7ShawZuLdhIs
Ef8cYUvKtj79gvV2x/2a7Yi/iU/6kmhxvIlPoJuryR/uz2JMCTqxN0Fxxzw3mn0J
8v1NJocarBvj4gbHHa6nb7gHREE3t/mAv2IuUTEeLsHEYXCMdw8C1vrK7ZuOCtdO
K117pHaJRqL6DCrLUUo4CmoX3n9ZT8URB985zAvm9kCNugucqAn+Gvhylhtob1Ta
xLcThJ5mKLPYm4T7QkQ7hllRQd/MtjFA9j7O2TQDBCuCCrqyjc/goNmAv1DCU05o
ROWrUYNaGQF4gl0yvM1h0j0oxbzI4sSQrEeK3ON55cwD4nU6itnoo5I53X/Zv2Pp
hicDzD1l9tWmBLWMRgqL
=gaqJ
-----END PGP SIGNATURE-----