[pdm-devel] [PATCH datacenter-manager v3 00/23] ] improve remote wizard

[Thomas Lamprecht]

On 21/08/2025 13:45, Lukas Wagner wrote:
> On Thu Aug 21, 2025 at 10:39 AM CEST, Dominik Csapak wrote:
>> ## Fingerprint confirmation dialogs
>>
>> Not sure if we want to be able to let the user confirm the fingerprint
>> so easily. On one hand it's very convenient, but maybe leads to users
>> simply clicking yes without understanding what's happening.
>>
>> If it's deemed too dangerous, I'd rework the series without this.
> 
> As said in v2, I think it's fine to have such a dialog, but I'd like to
> hear some other opinions before we apply this.
> 
> @Thomas, do you have an opinion on this?

+1, there's only so much one can do and Trust On First Use (TOFU) is a
widely established principle (e.g. SSH's host key verification).
Furthermore, having this now does not hinder us from improving it in
the future, like through some encoded "remote join info" that can be
copied from the PVE system, which would also include the fingerprint.
Note, that doing so does not really reduces the risk of a MITM attack
vector, because if an attacker can MITM the connection between
PDM and PVE, then it's equally likely that they can also MITM the one
between the admin's browser and PVE. IMO one option is not inherently
more likely/easier to happen than the other, the only bigger (security)
benefit of a "remote join info" would be of reusing the trust the
admin's (browser) has with the PVE system already, besides that it's
mostly for convenience.

FWIW, we could improve how we show the current fingerprint in general.
Currently it's viewable through the Certificate view in the node UI,
but one needs to open an extra window and one also needs to know which
cert to check, because if pveproxy-ssl.pem exists (e.g. ACME set up)
that one is used, otherwise it's pve-ssl.pem.
So just showing the fingerprint column by default is IMO not that
big of an help, maybe adding a short panel at the top detailing
the relevant TLS details for a direct API connection, which mostly
is the fingerprint though.

Anyhow, that's orthogonal to this, as said above, having such a
dialogue is certainly fine for now, it's common industry practice,
doesn't locks us in, admins that do care about security can still
ensure it's safe and for all others it's hard to rule out the MITM
vector completely, maybe some challenge response between PVE and
PDM might help, but again can still be done in the future.

> 
>>
>> # Future work
>>
> 
> [snip]
> 
>>  ui/src/remotes/wizard_page_connect.rs | 314 +++++++++++++++++---------
>>  ui/src/remotes/wizard_page_info.rs    | 121 +++++-----
>>  ui/src/remotes/wizard_page_nodes.rs   | 239 +++++++++++++++++++-
>>  ui/src/remotes/wizard_page_summary.rs |   5 +-
>>  ui/src/widget/mod.rs                  |   3 +
>>  ui/src/widget/pve_realm_selector.rs   | 123 ++++++++++
>>  15 files changed, 872 insertions(+), 203 deletions(-)
>>  create mode 100644 ui/src/widget/pve_realm_selector.rs
> 
> Gave this one another go. Code looks good to me, only two minor
> complaints about outdated doc comments and one question about the
> permissions for the tls-probe endpoint (see individual patches).
> 
> Consider this:
> 
> Reviewed-by: Lukas Wagner <l.wagner at proxmox.com>
> 
> Also tested this again, found two small issues:
>   - Seems like the realm selector is still not disabled when "Use
>     existing token" is selected
>   - When you modify something in the "Endpoints" tab (e.g. the IP
>     address for some endpoint), go back to "Settings" and then back to
>     "Endpoints", the changes are lost - I guess in this case the info is
>     fetched again from the API and the changes overwritten.
> 
> These could also be fixed in a follow-up, since these do not impeded the
> core functionality of the dialog, IMO.