On Thu, Jun 07, 2018 at 01:17:24PM +0200, Andrea Bolognani wrote: > On Thu, 2018-06-07 at 11:22 +0100, Daniel P. Berrangé wrote: > > On Thu, Jun 07, 2018 at 12:02:29PM +0200, Andrea Bolognani wrote: > > > While hints might be considered a reasonable fit for qcow2, I think > > > it's pretty hard to argue for embedding the NVRAM file in there, > > > which to me signals quite clearly that an archive containing the > > > disk image(s) *and* the configuration hints *and* other ancillary > > > files such as the NVRAM is the only way to build a solution that's > > > not dead on arrival. > > > > On a similar theme, I can imagine users wanting to provide a TPM > > data blob too, and for AMD SEV we'd need to be able to provide a > > DH key, and session blob too IIUC. > > I'm not familiar with the technologies you're talking about, but > all that sounds like something very security sensitive and not > something eg. the Fedora project would want to bake into their > cloud images. > > Perhaps we should keep in mind that this kind of archive format > lends itself quite naturally to both generic ready-made images and > custom, fully configured images: in the former case it would only > contain the few things mentione above, while in the latter it might > also have security sensitive data that's specific to the deployment > it's going to be used against.
I don't thonk there's any such distinction. A downstream user may build generic ready-made images, or fully configured app specific images. Both can contain the security sensitive data. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
