Re: [PATCH v3 04/25] migration: Cleanup TLS handshake hostname passing

[Fabiano Rosas <farosas@suse.de>]

Prasad Pandit <ppandit@redhat.com> writes:

> Hi,
>
> On Tue, 20 Jan 2026 at 16:41, Daniel P. Berrangé <berrange@redhat.com> wrote:
>> Normal default behaviour is that the hostname in the TLS certificate
>> MUST be validated against the hostname that is specified by the user
>> (or mgmt app) in the migration URI.
>>
>> The 'tls-hostname' migration parameter is an optional override that
>> replaces the hostname from the migration URI, to be used in scenarios
>> such as:
>>
>>  * The URI is a UNIX socket. eg the UNIX socket points to a proxy
>>    that is transporting data to the dest in some manner.  There is
>>    no way to know the hostname from the URI, so 'tls-hostname' must
>>    be provided
>>
>>  * The URI is pointing to a proxy that forwards to the real host.
>>    eg perhaps you setup an SSH tunnel from localhost, to the real
>>    target. QEMU must NOT validate the remote TLS cert against
>>    'localhost', so 'tls-hostname' must be provided by the user
>
> * I see, got it. Thank you for the explanation.
>
>> Whatever is usd to validate the TLS hostname, must be data that is
>> provided by the user in some manner.
>>
>> TL:DR: always use 'tls-hostname' if it is provided by the user,
>> otherwise always use the hostname from the migration URI,
>> otherwise do not provide a hostname.
>
> * So when 'tls-hostname' is not defined, it could be set to
> 's->hostname', then migration_tls_hostname() stays unchanged.
>

Setting the parameters.tls_hostname would expose the hostname in the
QAPI for the query commands. This is a change in behavior for this
series (and I don't think we'd want it either).

options.c contains the "internal API" that exposes the migration options
to the rest of the code. If there's somewhere to change the hostname
seen by the rest of the code, it's there.

> Thank you.
> ---
>   - Prasad