On Tue, Apr 03, 2018 at 08:11:05PM +0200, Jiri Denemark wrote: > On Tue, Apr 03, 2018 at 17:23:50 +0200, Ján Tomko wrote: > > From: Christophe Fergeau <cfergeau@xxxxxxxxxx> > > > > This commit adds a 'spice_tls_ciphers' parameter in > > qemu.conf which allows to configure which TLS ciphers > > SPICE will be using for its TLS connections. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1562032 > > > > Signed-off-by: Christophe Fergeau <cfergeau@xxxxxxxxxx> > > Signed-off-by: Ján Tomko <jtomko@xxxxxxxxxx> > > --- > > This is mostly useful as a workaround for missing crypto policies, > > so I'm not sure if it's upstream material. > > Are OpenSSL crypto policies supported upstream? If so, I think we should > just rely on them and leave this workaround for downstreams if they want > it. Also, what would we do if spice changed its TLS code to use another > library, wouldn't it force us to translate the parameters from OpenSSL > to the other library if this happens and this code is merged upstream? The latter is actually my biggest concern with this. I would really like to get SPICE to use the QEMU TLS creds framework, so we can do the normal -object tls-creds-x509 ... setup as we do for other parts ofo QEMU. This would mean SPICE using GNUTLS format for specifying ciphers. In fact the GNUTLS format specifies ciphers and TLS protocol versions - both of which the quoted bug is asking for - whereas this patch only specifies ciphers 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
