On 21/10/20 10:38, Daniel P. Berrangé wrote:
On Tue, Oct 20, 2020 at 07:22:03PM +0200, Paolo Bonzini wrote:
> On 20/10/20 18:22, Daniel P. Berrangé wrote:
>> @@ -153,6 +153,9 @@ int os_parse_cmd_args(int index, const char *optarg)
>> break;
>> #if defined(CONFIG_LINUX)
>> case QEMU_OPTION_enablefips:
>> + warn_report("-enable-fips is deprecated, please build QEMU with
"
>> + "the `libgcrypt` library as the cryptography provider
"
>> + "to enable FIPS compliance");
>> fips_set_state(true);
>> break;
>> #endif
>
> Should you also remove fips_set_state(true) and make fips_get_state()
> return the contents of /proc/sys/crypto/fips_enabled, so that VNC
> password authentication is disabled?
I did think about doing that, but decided that since my intention is
to delete all trace of fips_get_state / fips_set_state at the end of
the deprecation period, that it'd be saner just to leave the semantics
unchanged during the deprecation period.
But would it be correct? In order to have the advertised behavior of
"enable FIPS compliance just with procfs, no need to do anything in
QEMU" you need to disable VNC password authentication; so while
fips_set_state is an abomination, fips_get_state should remain.
Deprecation notices shouldn't really be associated with changes
in
functionality at time they are introduced.
I think you can consider it a bugfix since no one sets fips_enabled
without knowing what they're doing.
Paolo