1 files changed, 77 insertions, 0 deletions
diff --git a/results/classifier/118/virtual/1809252 b/results/classifier/118/virtual/1809252
new file mode 100644
index 00000000..ffdd0fc3
--- /dev/null
+++ b/results/classifier/118/virtual/1809252
@@ -0,0 +1,77 @@
+virtual: 0.932
+semantic: 0.906
+device: 0.862
+mistranslation: 0.842
+hypervisor: 0.841
+performance: 0.804
+architecture: 0.786
+network: 0.783
+vnc: 0.776
+permissions: 0.755
+peripherals: 0.737
+arm: 0.732
+risc-v: 0.726
+register: 0.715
+socket: 0.701
+ppc: 0.690
+kernel: 0.677
+graphic: 0.653
+debug: 0.618
+x86: 0.617
+user-level: 0.616
+files: 0.613
+VMM: 0.560
+PID: 0.550
+assembly: 0.541
+KVM: 0.539
+i386: 0.531
+boot: 0.515
+TCG: 0.502
+
+Password authentication in FIPS-compliant mode
+
+The documentation states, that:
+
+"The VNC protocol has limited support for password based authentication. (...) Password authentication is not supported when operating in FIPS 140-2 compliance mode as it requires the use of the DES cipher."
+
+Would it be possible for qemu to use a different cipher and re-enable password as an option in VNC console? Is there a technical reason for not using a stronger cipher?
+
+On 12/20/18 6:59 AM, Tomasz Barański wrote:
+> Public bug reported:
+> 
+> The documentation states, that:
+> 
+> "The VNC protocol has limited support for password based authentication.
+> (...) Password authentication is not supported when operating in FIPS
+> 140-2 compliance mode as it requires the use of the DES cipher."
+> 
+> Would it be possible for qemu to use a different cipher and re-enable
+> password as an option in VNC console? Is there a technical reason for
+> not using a stronger cipher?
+
+The technical reason is that there are no other VNC endpoints out there 
+that support a different cipher. The VNC protocol itself declares what 
+all compliant servers/clients must use - and that spec is what makes the 
+non-FIPS-compliant requirement.  You wouldn't have to patch just qemu, 
+but every other VNC endpoint out there that you want to interoperate 
+with a patched qemu.  But it's really not worth doing that when there 
+are already better solutions available.  That is, rather than trying to 
+fix VNC, just use an alternative protocol that doesn't have a baked-in 
+authentication limitation in the first place - namely, Spice.
+
+-- 
+Eric Blake, Principal Software Engineer
+Red Hat, Inc.           +1-919-301-3266
+Virtualization:  qemu.org | libvirt.org
+
+
+The VNC password authentication scheme is not extensible. It is unfixably broken by design.
+
+QEMU provides the SASL authentication scheme for VNC which allows for strong authentication, when combined with the VeNCrypt authentication scheme that uses TLS.
+
+These extensions are supported by the gtk-vnc client used by remote-viewer, virt-viewer, virt-manager, GNOME Boxes and more.  Other VNC clients are also known to implement VeNCrypt, though SASL support is less wide spread.
+
+From a QEMU POV, there's nothing more we need todo really - any remaining gaps are client side.
+
+I understand. Thank you, guys!
+