<div dir="ltr"><div><div>Yea,</div><div><br></div>My fix is similar except I moved the code to before the switch - this bug really isn't specific to PAM and other XAUTH algorithms need to do the same thing.  I'll push my fix<br><br></div>Andrew<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 19 October 2017 at 15:41, Antony Antony <span dir="ltr"><<a href="mailto:antony@phenome.org" target="_blank">antony@phenome.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Oct 19, 2017 at 10:38:57AM -0400, Andrew Cagney wrote:<br>
> where it sends out the AUTH reply (an st_event), and a short while later<br>
> sends out an XAUTH request (an st_send_xauth_event, recent changes mean it<br>
> is generated from scratch and doesn't replace the AUTH reply?).<br>
><br>
> With this, the problem I'm seeing is that when the initiator comes back<br>
> with its XAUTH reply, the responder, in xauth_launch_authent() needs to<br>
> cancel both the RETRANSMIT and the SEND_XAUTH but it only cancels the first<br>
> and only when PAM.  This lets SEND_XAUTH fire repeatedly and even after PAM<br>
> finishes and the final reply sent, and its code uses change_state() to<br>
> blungeon the state back to XAUTH_R0 resulting in much confusion.<br>
<br>
</span>here is a fix  that comes to my mind.<br>
I am hopping this works for aggressive mode and main mode.<br>
<span class="HOEnZb"><font color="#888888"><br>
-antony<br>
</font></span></blockquote></div><br></div>