Tries to use capabilities and SASL mechanisms that are not available

[progval]

Hi,

I just ran Sopel 6.6.9 with this config:

[core]
nick = Sopel
host = 0.0.0.0
use_ssl = false
port = 49657
owner = me
channels = 
timeout = 5
auth_username = jilles
auth_password = sesame
auth_method = sasl

When connecting to a server that advertises it supports only sasl=EXTERNAL, Sopel requests a bunch of capabilities and tries to use PLAIN anyway:

1575920338.485 C: CAP LS 302
1575920338.485 S: CAP * LS :sasl=EXTERNAL
1575920338.485 C: NICK Sopel
1575920338.485 C: USER sopel +iw Sopel :Sopel: https://sopel.chat
1575920338.486 C: CAP REQ multi-prefix
1575920338.486 S: CAP Sopel NAK :multi-prefix
1575920338.486 C: CAP REQ away-notify
1575920338.486 S: CAP Sopel NAK :away-notify
1575920338.486 C: CAP REQ cap-notify
1575920338.486 S: CAP Sopel NAK :cap-notify
1575920338.486 C: CAP REQ server-time
1575920338.486 S: CAP Sopel NAK :server-time
1575920338.486 C: CAP REQ account-notify
1575920338.486 S: CAP Sopel NAK :account-notify
1575920338.486 C: CAP REQ extended-join
1575920338.486 S: CAP Sopel NAK :extended-join
1575920338.486 C: CAP REQ account-tag
1575920338.486 S: CAP Sopel NAK :account-tag
1575920338.486 C: CAP REQ sasl
1575920338.486 S: CAP Sopel ACK :sasl
1575920338.530 C: AUTHENTICATE PLAIN

Is this intended behavior?

[dgw]

Is this intended behavior?

Only in that the code assumes PLAIN if no mechanism is specified in the config file. (This is slightly updated from 6.6.9, as the forthcoming 7.0 release supports separate server/nick authentication.)

sopel/sopel/coretasks.py

Lines 603 to 611 in f4db54f

	if bot.config.core.auth_method == 'sasl':
	password = bot.config.core.auth_password
	mech = bot.config.core.auth_target
	elif bot.config.core.server_auth_method == 'sasl':
	password = bot.config.core.server_auth_password
	mech = bot.config.core.server_auth_sasl_mech
	if not password:
	return
	mech = mech or 'PLAIN'

If you specify auth_target = EXTERNAL yourself in the config, does authentication then work? (I'm honestly not sure if anyone has ever tested non-PLAIN mechanisms.)

A lot of work has gone into building a foundation for Sopel to handle feature flags/tokens better at runtime (e.g. servers' MYINFO and ISUPPORT replies) in 7.0—which is due out later this month! (🤞 🚀) Improving the capability negotiation is a good next step, so I'll drop this in 7.1 as a "Tweak" (enhancement) to work on.

[Exirel]

@progval reading the code for Sopel 6.6.9, I think you need to define auth_target in your configuration file (under the [core] section).

See also: https://github.com/sopel-irc/sopel/blob/6.6.x/sopel/coretasks.py#L574-L581

[dgw]

Apparently I started working on this a while back and forgot about it. Partial "fix" (more of a workaround) is in #1928.

[dgw]

@progval If you're still interested, I spruced up #1928 and it should be ready to have stuff thrown at it.

[Exirel]

AFAICT, it looks like Sopel will now raise an exception when the configuration and the capabilities are not good, so we should be good. Let's close this.

[dgw]

@Exirel The idea was to try and get feedback from the original reporter, @progval, before closing.

[progval]

Hi,

Yes, sorry, this issue looks solved.

But the linked PR seems to introduce an important bug, which should prevent Sopel from authenticating at all, I'll open an other issue

EDIT: #1974

[progval]

Er, actually, here is what happens now (with the same config as above):

1604131995.689 C: CAP LS 302
1604131995.689 S: CAP * LS :sasl=EXTERNAL
1604131995.689 C: NICK Sopel
1604131995.689 C: USER sopel 0 * :Sopel: https://sopel.chat/
1604131995.690 C: CAP REQ echo-message
1604131995.690 S: CAP Sopel NAK :echo-message  
1604131995.690 C: CAP REQ multi-prefix
1604131995.690 S: CAP Sopel NAK :multi-prefix  
1604131995.690 C: CAP REQ away-notify
1604131995.690 S: CAP Sopel NAK :away-notify   
1604131995.690 C: CAP REQ cap-notify
1604131995.690 S: CAP Sopel NAK :cap-notify
1604131995.690 C: CAP REQ server-time
1604131995.690 S: CAP Sopel NAK :server-time   
1604131995.690 C: CAP REQ account-notify
1604131995.690 S: CAP Sopel NAK :account-notify
1604131995.690 C: CAP REQ extended-join
1604131995.690 S: CAP Sopel NAK :extended-join 
1604131995.690 C: CAP REQ account-tag
1604131995.690 S: CAP Sopel NAK :account-tag   
1604131995.690 C: CAP REQ sasl
1604131995.690 S: CAP Sopel ACK :sasl
1604131995.738 C: PRIVMSG  :Unexpected error (ConfigurationError: SASL mechanism 'PLAIN' is not advertised by this server.) from  at 2020-10-31 09:13:15.735874. Message was: sasl

There shouldn't be PRIVMSGs this early in the connection (plus, it's missing a target)

[Exirel]

@progval do you have channel logging enabled? Note that this error message should be present in your standard logs too, which is where it's important. The problem with the channel log is something to be address in another issue/PR.

Aside from that, there is already a PR to quit when the SASL config is invalid, see #1971 for that. So I think we can consider this fixed when it is merged.