On 03.05.2012, at 11:09, Daniel P. Berrange wrote: > On Thu, May 03, 2012 at 11:06:18AM +0200, Alexander Graf wrote: >> >> On 03.05.2012, at 11:03, Daniel P. Berrange wrote: >> >>> On Thu, May 03, 2012 at 11:01:29AM +0200, Alexander Graf wrote: >>>> >>>> On 03.05.2012, at 10:57, Daniel P. Berrange wrote: >>>> >>>>> On Thu, May 03, 2012 at 10:51:15AM +0200, Alexander Graf wrote: >>>>>> >>>>>> On 03.05.2012, at 10:29, Daniel P. Berrange wrote: >>>>>> >>>>>>> On Wed, May 02, 2012 at 03:32:56PM -0400, Paul Moore wrote: >>>>>>>> FIPS 140-2 requires disabling certain ciphers, including DES, which is >>>>>>>> used >>>>>>>> by VNC to obscure passwords when they are sent over the network. The >>>>>>>> solution for FIPS users is to disable the use of VNC password auth >>>>>>>> when the >>>>>>>> host system is operating in FIPS mode. >>>>>> >>>>>> So that means "no password" is more secure according to FIPS than >>>>>> "DES encrypted password"? >>>>> >>>>> No, FIPS is not making statements about the choice of auth methods. >>>>> FIPS is concerned with what encryption algorithms an application uses. >>>>> The requirements about whether authentication is required & what sort, >>>>> is upto other specifications (eg Common Criteria) to decide. >>>> >>>> Hrm, so short-term this fixes things. But long-term, I think the >>>> better solution would be to implement the tight security model and >>>> use a real cipher: >>> >>> That is certainly possible, but shouldn't have any bearing on whether >>> this patch is accepted. Note that QEMU already implements VeNCrypt >>> and SASL extensions both of which provide strong security >> >> Hmm. Isn't the syslog message misleading then? Also, why would the >> whole password parameter be blocked then? > > The password parameter is irrelevant for VeNCrypt & SASL authentication > types. They are configured via other parameters.
Ah, an error message hinting to the alternatives would be nice then :). Alex