)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"245dd742f21d7b75cc026dcf93278d78c9d558b8","unresolved":true,"context_lines":[{"line_number":7,"context_line":"Add none rfb neigotiation type for vnc auth_schemes"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"As we need to use `vencrypt` rfb neigotiation to reset the vnc password,"},{"line_number":10,"context_line":"we should add `none` type to auth_schemes for the tempest case."},{"line_number":11,"context_line":""},{"line_number":12,"context_line":"Co-Authored-By: Brin Zhang \u003czhangbailin@inspur.com\u003e"},{"line_number":13,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"88456be7_9e70fb2a","line":10,"updated":"2021-03-01 10:03:13.000000000","message":"Please explain why we need to add \u0027none\u0027 to the config explicitly now. If the none authtype worked before the patch [1] without extra configuration but does not work after it, then I guess this will impact the Wallaby upgrade as well. Does the deployers need to change the configuration during the upgrade to keep the VNC working as before?\n\n[1] https://review.opendev.org/c/openstack/nova/+/622336","commit_id":"4c55dd5dd7f37230bf2aa13095129cc1993ce780"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"e921657b2eb2f574ac26b973f8e5622d33db33b9","unresolved":true,"context_lines":[{"line_number":7,"context_line":"Add none rfb neigotiation type for vnc auth_schemes"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"As we need to use `vencrypt` rfb neigotiation to reset the vnc password,"},{"line_number":10,"context_line":"we should add `none` type to auth_schemes for the tempest case."},{"line_number":11,"context_line":""},{"line_number":12,"context_line":"Co-Authored-By: Brin Zhang \u003czhangbailin@inspur.com\u003e"},{"line_number":13,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"23bcd4e0_f0ed4c39","line":10,"in_reply_to":"88456be7_9e70fb2a","updated":"2021-03-01 10:10:40.000000000","message":"Yes, this isn\u0027t something we should do. From the original spec that introduced this option [1]:\n\n  When enabling vencrypt for an existing deployment, two stages will be required.\n  Initially the [vnc]auth_schemes configuration parameter will need to list both\n  vencrypt and none auth schemes. This allows the proxy to connect to both\n  pre-existing deployed compute hosts which do not have TLS turned on and newly\n  updated compute with TLS. Once all compute hosts have been updated to enable\n  TLS, the [vnc] auth_schemes configuration parameter can be switched to only\n  permit vencrypt.\n\nSo if you\u0027re having to enable this, that suggests TLS is not properly configured. Setting none merely masks over the issue\n\n[1] https://specs.openstack.org/openstack/nova-specs/specs/queens/implemented/websocket-proxy-to-host-security.html#other-deployer-impact","commit_id":"4c55dd5dd7f37230bf2aa13095129cc1993ce780"}]}