Skip to content
  • Daniel P. Berrangé's avatar
    d41997e4
    crypto: mandate a hostname when checking x509 creds on a client · d41997e4
    Daniel P. Berrangé authored
    
    
    Currently the TLS session object assumes that the caller will always
    provide a hostname when using x509 creds on a client endpoint. This
    relies on the caller to detect and report an error if the user has
    configured QEMU with x509 credentials on a UNIX socket. The migration
    code has such a check, but it is too broad, reporting an error when
    the user has configured QEMU with PSK credentials on a UNIX socket,
    where hostnames are irrelevant.
    
    Putting the check into the TLS session object credentials validation
    code ensures we report errors in only the scenario that matters.
    
    Reviewed-by: default avatarEric Blake <eblake@redhat.com>
    Signed-off-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
    Message-Id: <20220304193610.3293146-2-berrange@redhat.com>
    Signed-off-by: default avatarEric Blake <eblake@redhat.com>
    d41997e4
    crypto: mandate a hostname when checking x509 creds on a client
    Daniel P. Berrangé authored
    
    
    Currently the TLS session object assumes that the caller will always
    provide a hostname when using x509 creds on a client endpoint. This
    relies on the caller to detect and report an error if the user has
    configured QEMU with x509 credentials on a UNIX socket. The migration
    code has such a check, but it is too broad, reporting an error when
    the user has configured QEMU with PSK credentials on a UNIX socket,
    where hostnames are irrelevant.
    
    Putting the check into the TLS session object credentials validation
    code ensures we report errors in only the scenario that matters.
    
    Reviewed-by: default avatarEric Blake <eblake@redhat.com>
    Signed-off-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
    Message-Id: <20220304193610.3293146-2-berrange@redhat.com>
    Signed-off-by: default avatarEric Blake <eblake@redhat.com>
Loading