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. -- 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
