diff options
author | Christophe Fergeau <cfergeau@redhat.com> | 2014-03-13 16:16:00 +0100 |
---|---|---|
committer | Christophe Fergeau <cfergeau@redhat.com> | 2014-11-24 17:37:17 +0100 |
commit | 1ac4dfb3170bd970c90ff970e9f93775867b83e5 (patch) | |
tree | 68477e720377d16d2132e30b66b01734b6a334c2 /server/spice.h | |
parent | 24bebaa8558f41224cea7f730933bf25899a12a8 (diff) | |
download | spice-1ac4dfb3170bd970c90ff970e9f93775867b83e5.tar.gz spice-1ac4dfb3170bd970c90ff970e9f93775867b83e5.tar.xz spice-1ac4dfb3170bd970c90ff970e9f93775867b83e5.zip |
Don't set SpiceLinkReply::pub_key if client advertises SASL cap
If the client advertises the SASL cap, it means it guarantees it will be
able to use SASL if the server supports, and that it does not need a valid
SpiceLinkReply::pub_key field when using SASL.
When the client cap is set, we thus don't need to create a RSA public key
if SASL is enabled server side.
The reason for needing client guarantees about not looking at the pub_key
field is that its presence and size is hardcoded in the protocol, but in
some hardened setups (using fips mode), generating a RSA 1024 bit key as
expected is forbidden and fails. With this new capability, the server
knows the client will be able to handle SASL if needed, and can skip
the generation of the key altogether. This means that on the setups
described above, SASL authentication has to be used.
Diffstat (limited to 'server/spice.h')
0 files changed, 0 insertions, 0 deletions