Hi Michal, On Fri, Oct 30, 2026 at 11:43 AM Michal Prívozník <mprivozn@redhat.com> wrote:
On 10/30/26 09:42, Erik Huelsmann wrote:
Hi Michal,
When I wrote Sys::Async::Virt 2 years ago, I extensively studied the SASL code in libvirt.
At the time, I thought I saw patters where the following sequence might be going on: INIT -> START -> STEP -> START
The second START would be issued after setting up the correct authentication data after an authentication had been challenged. Do you see the same pattern? If so, then the second START will already have the "started" boolean set to true, even when it hasn't. Using a state machine with a single "state" variable would prevent that.
Ah, if that's the case then my patch is incorrect, though the only thing needed is to drop some checks to allow START after STEP again. I have not seen that in my testing, though. And looking into remoteAuthSASL() I don't see a way that a client could call the sequence from your example. The only sequence possible is INIT -> START [-> STEP [-> STEP ...]].
Well, this line: https://gitlab.com/libvirt/libvirt/-/blob/master/src/remote/remote_driver.c?... in combination with this "goto": https://gitlab.com/libvirt/libvirt/-/blob/master/src/remote/remote_driver.c?... led me to believe that it's possible to see two START commands on the same connection, which, I must say, confused me a lot at the time. I don't think my client supports the pattern, but then again, it uses a Perl implementation of the SASL protocol, not libsasl2. Regards, -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.