restructure results

1 files changed, 62 insertions, 0 deletions

diff --git a/results/classifier/zero-shot/108/other/1809252 b/results/classifier/zero-shot/108/other/1809252
new file mode 100644
index 000000000..677572865
--- /dev/null
+++ b/results/classifier/zero-shot/108/other/1809252
@@ -0,0 +1,62 @@
+semantic: 0.906
+other: 0.894
+device: 0.862
+performance: 0.804
+network: 0.783
+vnc: 0.776
+permissions: 0.755
+socket: 0.701
+graphic: 0.653
+debug: 0.618
+files: 0.613
+PID: 0.550
+KVM: 0.539
+boot: 0.515
+
+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!
+