I have requireauth as no, because I think it's more important for me to see the discussions that happen on the network than to be identified with SASL.
Today ChatSpike seems to be broken again and I was getting registration timeouts because of *sasl which I believe should only abort connecting if requireauth is yes.
I have requireauth as no, because I think it's more important for me to see the discussions that happen on the network than to be identified with SASL.
Today ChatSpike seems to be broken again and I was getting registration timeouts because of *sasl which I believe should only abort connecting if requireauth is yes.
##
<bountysource-plugin>
---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/23355073-sasl-shouldn-t-timeout-when-requireauth-is-no?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github).
</bountysource-plugin>
<!-- github-sync-id:91992177 -->
The AUTHENTICATE command MUST be used before registration is complete and with the sasl capability enabled. To enforce the former, it is RECOMMENDED to only send CAP END when the SASL exchange is completed or needs to be aborted. Clients SHOULD be prepared for timeouts at all times during the SASL authentication.
> The AUTHENTICATE command MUST be used before registration is complete and with the sasl capability enabled. To enforce the former, it is RECOMMENDED to only send CAP END when the SASL exchange is completed or needs to be aborted. _Clients SHOULD be prepared for timeouts at all times during the SASL authentication._
From http://ircv3.net/specs/extensions/sasl-3.1.html, the first chapter of _The AUTHENTICATE command_.
<!-- github-comment-id:122229588 -->
I've stumbled upon this problem too. This network I'm on is doing some maintenance as we speak, and in result of this the services server is down, so there's currently no SASL authentication possible. This is causing ZNC to fail to connect repeatedly while it should just succeed.
I've stumbled upon this problem too. This network I'm on is doing some maintenance as we speak, and in result of this the services server is down, so there's currently no SASL authentication possible. This is causing ZNC to fail to connect repeatedly while it should just succeed.
<!-- github-comment-id:140114370 -->
It seems that it's easier to just keep *sasl unloaded on ChatSpike (which is the only network where I see this) until this is fixed.
They don't have vhosts so there is no fear of being joined to channel before it activates and I identify with *cert which is still the best way until SASL REAUTH (https://github.com/znc/znc/issues/949) becomes more widely used. They also have NickServ module (ajoin) to join me to channels on connect so being unable to join channels isn't an issue either.
It seems that it's easier to just keep *sasl unloaded on ChatSpike (which is the only network where I see this) until this is fixed.
They don't have vhosts so there is no fear of being joined to channel before it activates and I identify with *cert which is still the best way until SASL REAUTH (https://github.com/znc/znc/issues/949) becomes more widely used. They also have NickServ module (ajoin) to join me to channels on connect so being unable to join channels isn't an issue either.
<!-- github-comment-id:149642472 -->
2015-12-02 19:05:58+0200 -- Channel #ircv3: 125 nicks (1 op, 0 voices, 124 normals)
2015-12-02 19:06:52+0200 -- Channel created on 2011-01-26 23:05:35+0200
2015-12-02 19:45:15+0200 < Mikaela> ZNC being idiot with SASL probably isn't reason enough to change wording in SASL spec to require timeout unless the user wants to not connect to network without being identified? https://github.com/znc/znc/issues/984
2015-12-02 19:47:23+0200 < dx> uhhh what
2015-12-02 19:47:50+0200 < Mikaela> the last comment, all registration timeouts were caused by the SASL module
2015-12-02 19:48:09+0200 < dx> how do you know that?
2015-12-02 19:48:54+0200 < Mikaela> by having the knowledge that ZNC has this bug and that freenode services went down and having the exact same error on ChatSpike and it getting fixed by following advice by DarthGandalf and temporarily unloading *SASL
2015-12-02 19:49:55+0200 < dx> okay
2015-12-02 19:50:09+0200 < dx> because that log is rather opaque
2015-12-02 19:50:44+0200 < dx> anyway your issue seems straightforward, znc not honoring its own setting to not require auth
2015-12-02 19:51:09+0200 < dx> ("straightforward", i say, after rereading the same thing ten times)
2015-12-02 19:53:50+0200 < dx> might help to change the subject to say "sasl *shouldn't* timeout when requireauth is no"
2015-12-02 19:54:39+0200 < Mikaela> ok
2015-12-02 19:54:39+0200 < Mikaela> may I paste this discussion to it as from you I realize that the issue is not as detailed or explain enough?
2015-12-02 19:54:41+0200 < dx> ..although the timeout comes from the server, not from znc, so maybe it should timeout
2015-12-02 19:54:54+0200 < dx> yeah sure.
```
2015-12-02 19:05:58+0200 -- Channel #ircv3: 125 nicks (1 op, 0 voices, 124 normals)
2015-12-02 19:06:52+0200 -- Channel created on 2011-01-26 23:05:35+0200
2015-12-02 19:45:15+0200 < Mikaela> ZNC being idiot with SASL probably isn't reason enough to change wording in SASL spec to require timeout unless the user wants to not connect to network without being identified? https://github.com/znc/znc/issues/984
2015-12-02 19:47:23+0200 < dx> uhhh what
2015-12-02 19:47:50+0200 < Mikaela> the last comment, all registration timeouts were caused by the SASL module
2015-12-02 19:48:09+0200 < dx> how do you know that?
2015-12-02 19:48:54+0200 < Mikaela> by having the knowledge that ZNC has this bug and that freenode services went down and having the exact same error on ChatSpike and it getting fixed by following advice by DarthGandalf and temporarily unloading *SASL
2015-12-02 19:49:55+0200 < dx> okay
2015-12-02 19:50:09+0200 < dx> because that log is rather opaque
2015-12-02 19:50:44+0200 < dx> anyway your issue seems straightforward, znc not honoring its own setting to not require auth
2015-12-02 19:51:09+0200 < dx> ("straightforward", i say, after rereading the same thing ten times)
2015-12-02 19:53:50+0200 < dx> might help to change the subject to say "sasl *shouldn't* timeout when requireauth is no"
2015-12-02 19:54:39+0200 < Mikaela> ok
2015-12-02 19:54:39+0200 < Mikaela> may I paste this discussion to it as from you I realize that the issue is not as detailed or explain enough?
2015-12-02 19:54:41+0200 < dx> ..although the timeout comes from the server, not from znc, so maybe it should timeout
2015-12-02 19:54:54+0200 < dx> yeah sure.
```
<!-- github-comment-id:161380442 -->
Just a quick note what the RequireAuth setting does: If it is true, ZNC disconnects when it managed to connect to the IRCd without a successfull authentication (or if authentication failed).
So what you are really asking for in this bug: A timeout mechanism should be added to the SASL module where, after a certain time, it aborts the authentication attempt (send AUTHENTICATE *, according to the SASL spec) and continue capability negotiation (ResumeCap()).
If the server has internal problems, perhaps the bug is also that the IRCd doesn't have any timeouts for authentication?
Just a quick note what the `RequireAuth` setting does: If it is true, ZNC disconnects when it managed to connect to the IRCd without a successfull authentication (or if authentication failed).
So what you are really asking for in this bug: A timeout mechanism should be added to the SASL module where, after a certain time, it aborts the authentication attempt (send `AUTHENTICATE *`, according to the SASL spec) and continue capability negotiation (`ResumeCap()`).
If the server has internal problems, perhaps the bug is also that the IRCd doesn't have any timeouts for authentication?
<!-- github-comment-id:161382526 -->
< dx> ..although the timeout comes from the server, not from znc, so maybe it should timeout
What I meant to say there is that the issue can be interpreted both ways:
A server connection timeout shouldn't happen (as in, should be avoided)
A sasl authentication timeout on ZNC's side should happen before the server one, to avoid losing the connection.
I sort-of-confused myself with both meanings of timeout.
If the server has internal problems, perhaps the bug is also that the IRCd doesn't have any timeouts for authentication?
Possibly true, but this behavior is also allowed by the sasl-3.1 spec. The client should have its own timeout like you mentioned.
> < dx> ..although the timeout comes from the server, not from znc, so maybe it should timeout
What I meant to say there is that the issue can be interpreted both ways:
- A server connection timeout shouldn't happen (as in, should be avoided)
- A sasl authentication timeout on ZNC's side should happen before the server one, to avoid losing the connection.
I sort-of-confused myself with both meanings of timeout.
> If the server has internal problems, perhaps the bug is also that the IRCd doesn't have any timeouts for authentication?
Possibly true, but this behavior is also allowed by the sasl-3.1 spec. The client should have its own timeout like you mentioned.
<!-- github-comment-id:161385341 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
I have requireauth as no, because I think it's more important for me to see the discussions that happen on the network than to be identified with SASL.
Today ChatSpike seems to be broken again and I was getting registration timeouts because of *sasl which I believe should only abort connecting if requireauth is yes.
--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/23355073-sasl-shouldn-t-timeout-when-requireauth-is-no?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github).From http://ircv3.net/specs/extensions/sasl-3.1.html, the first chapter of The AUTHENTICATE command.
I've stumbled upon this problem too. This network I'm on is doing some maintenance as we speak, and in result of this the services server is down, so there's currently no SASL authentication possible. This is causing ZNC to fail to connect repeatedly while it should just succeed.
It seems that it's easier to just keep *sasl unloaded on ChatSpike (which is the only network where I see this) until this is fixed.
They don't have vhosts so there is no fear of being joined to channel before it activates and I identify with *cert which is still the best way until SASL REAUTH (https://github.com/znc/znc/issues/949) becomes more widely used. They also have NickServ module (ajoin) to join me to channels on connect so being unable to join channels isn't an issue either.
And this bug hit me in combination to that and I seriously doubt that I am the only one who suffered it.
Just a quick note what the
RequireAuthsetting does: If it is true, ZNC disconnects when it managed to connect to the IRCd without a successfull authentication (or if authentication failed).So what you are really asking for in this bug: A timeout mechanism should be added to the SASL module where, after a certain time, it aborts the authentication attempt (send
AUTHENTICATE *, according to the SASL spec) and continue capability negotiation (ResumeCap()).If the server has internal problems, perhaps the bug is also that the IRCd doesn't have any timeouts for authentication?
What I meant to say there is that the issue can be interpreted both ways:
I sort-of-confused myself with both meanings of timeout.
Possibly true, but this behavior is also allowed by the sasl-3.1 spec. The client should have its own timeout like you mentioned.