If you start a standalone server with TLS enabled, and two users connect using TLS and /whois one another, "secure network path" is not shown in RPL_WHOISSECURE, though it should be, as they are both on the same server.
This appears to be caused by compute_secure_path_groups() only being called in response to a server link or delink, not at startup. This leaves the server's sid initialized to 0.
I verified that calling compute_secure_path_groups() in main() fixes the issue.
It's difficult to test this with the pytest testing harness due to the way containers are built up and torn down. There is currently a test that shows this issue, but it must be run out of order:
python -m pytest secure_path/test_review_findings.py::test_same_server_tls_clients_share_secure_path -m tls -v
If this test runs in order as part of the normal test suite, it reuses the existing ircd_tls_network fixture. That fixture has already had a leaf server link, meaning compute_secure_path_groups() has already been called at least once.
If you start a standalone server with TLS enabled, and two users connect using TLS and /whois one another, "secure network path" is not shown in RPL_WHOISSECURE, though it should be, as they are both on the same server.
This appears to be caused by
compute_secure_path_groups()only being called in response to a server link or delink, not at startup. This leaves the server'ssidinitialized to 0.I verified that calling
compute_secure_path_groups()inmain()fixes the issue.It's difficult to test this with the pytest testing harness due to the way containers are built up and torn down. There is currently a test that shows this issue, but it must be run out of order:
If this test runs in order as part of the normal test suite, it reuses the existing
ircd_tls_networkfixture. That fixture has already had a leaf server link, meaningcompute_secure_path_groups()has already been called at least once.