<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - spice-gtk / remote-viewer SSL verification behavior" href="https://bugs.freedesktop.org/show_bug.cgi?id=94063#c2">Comment # 2</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - spice-gtk / remote-viewer SSL verification behavior" href="https://bugs.freedesktop.org/show_bug.cgi?id=94063">bug 94063</a> from <a class="email" href="mailto:f.gruenbichler@proxmox.com" title="Fabian Grünbichler <f.gruenbichler@proxmox.com>"> Fabian Grünbichler</a> <pre>Original reporter here. For our use case, either 1 or 2 is probably fine, but I would prefer version 1 because there are no (potentially failing) dependencies on the user's or OS trust store. Version 2 seems to be stricter, but IMHO only limits the possible valid configurations without any security benefit. If an attacker is able to modify the configuration file and changes the ca parameter (e.g., for MITM purposes), they can currently already include their root certificate and pass all checks. If the attacker cannot change the configuration file, I see no reason to require an explicit pinning of the root in addition to the intermediate certificate. OTOH, I might have missed a different setup where this distinction is relevant. Requiring a trusted root certificate if there is no ca(-file) parameter seems reasonable.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>