Hi Michal, On Fri, Oct 30, 2026 at 11:43 AM Michal Prívozník <[email protected]> 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?ref_type=heads#L3769 in combination with this "goto": https://gitlab.com/libvirt/libvirt/-/blob/master/src/remote/remote_driver.c?ref_type=heads#L3786 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.
