View Issue Details

IDProjectCategoryView StatusLast Update
0004104unrealmodule apipublic2012-10-15 15:30
Reportersyzop Assigned Tosyzop  
Status resolvedResolutionfixed 
Product Version3.2.10-rc1 
Fixed in Version3.2.10-rc1 
Summary0004104: modulize client CAP system & add disable options
DescriptionModulize the new CAP system, so modules can add/remove clicap's... similar to how ISupport, User Modes, and so on are modulized.
This means moving part of m_cap.c to the core.

Additionally, when at it, add the possibility to disable SASL.

Also add the possibility to disable CAP altogether.

Since all those happen pre-auth, if a serious (crash)bug has been found it should be possible to quickly disable the feature.
TagsNo tags attached.
3rd party modules


related to 0004131 resolvednenolod modulize client CAP system 
child of 0003915 resolvedsyzop Unreal3.2.10 TODO 
child of 0004301 resolvedsyzop Unreal3.2.10 TODO 



2012-04-12 02:39

reporter   ~0016979

idea: enable sasl conditionally based on whether or not services requests it in PROTOCTL. thoughts?

this would allow clients to skip trying to do SASL auth on networks which don't support it (such as anope networks).


2012-04-12 21:17

administrator   ~0016980

Yes, good point.
Because right now with SASL, the client just waits for XX seconds and times out?


2012-04-18 13:48

reporter   ~0016983

actually, this wouldn't work because we don't share global capability data. i guess it would need to be a setting. :)

obviously the real fix here is for anope to implement SASL support, but they probably won't do that for a while.


2012-04-29 11:17

administrator   ~0016985

Last edited: 2012-04-29 11:18

Well, SASL is an option, it's not mandatory for services to implement. And, of course, there are also servers (and networks) without services.

In any case, this new feature shouldn't cause a delay for networks that don't use SASL-capable services.
Perhaps we should just default it to off, and have the admin enable it explicitly.
Auto-discovery is also an option, but I really get the feeling that we are making things overcomplicated then.

(If a network does use SASL-capable services and they are temporarily down and you get a delay then.. so be it.. but if you never have SASL-capable services connected, the delay is just a waste)


2012-05-04 18:11

reporter   ~0016987

perhaps a fix with sasl is to specify a sasl_server option. this could avoid auto-discovery of sasl agents.


2012-05-05 10:45

administrator   ~0016988

What I have in mind is something like set::enable-sasl yes/no or set::options::sasl.
What is also possible is set::sasl-server <servername>. Only if this is specified enable SASL. And no longer use SERVICES_SERVER for this.

Is that last option what you meant? Or something else?


2012-05-07 16:52

administrator   ~0016993
- SASL now needs to be enabled explicitly by setting a set::sasl-server.
  If this is not set, then SASL is off and not advertised.
  If the specified server is not connected, then SASL is off as well.
  This prevents unnecessary delay (and the inability for some clients to
  get online) when SASL is not in use or when the SASL server is down.

I realized it would be good to not advertise SASL when the sasl server is down, so that required adding some hacks (which are necessary whether CAP gets modulized or not). Clients such as KVIrc are unable to get online if SASL is advertised and the SASL server does not respond.

The original target for this bug, the modulization of CAP, still needs to be done.


2012-05-11 12:07

reporter   ~0017001

set::sasl-server is a good approach, indeed.

i'm going to add this to charybdis as a hint for advertising the sasl capability i think :)


2012-10-06 12:31

administrator   ~0017152

the disable feature is assigned to me, mandatory for 3.2.10.
the modularization is not a release target, and not assigned to me.


2012-10-15 15:28

administrator   ~0017175

Last edited: 2012-10-15 15:28
- Added set::options::disable-cap, which can be used to disable the
  new CAP support (0004104).

The ability to use, or not use, SASL was already implemented.

This means only the modularization of CAP is left, which is now tracked in 0004131.

This issue can be closed.

Issue History

Date Modified Username Field Change
2012-04-09 10:43 syzop New Issue
2012-04-09 10:43 syzop Relationship added child of 0003915
2012-04-12 02:39 nenolod Note Added: 0016979
2012-04-12 21:17 syzop Note Added: 0016980
2012-04-18 13:48 nenolod Note Added: 0016983
2012-04-29 11:17 syzop Note Added: 0016985
2012-04-29 11:18 syzop Note Edited: 0016985
2012-05-04 18:11 nenolod Note Added: 0016987
2012-05-05 10:45 syzop Note Added: 0016988
2012-05-07 16:27 syzop Assigned To => syzop
2012-05-07 16:27 syzop Status new => assigned
2012-05-07 16:52 syzop Note Added: 0016993
2012-05-07 16:52 syzop Assigned To syzop =>
2012-05-07 16:52 syzop Status assigned => acknowledged
2012-05-11 12:07 nenolod Note Added: 0017001
2012-10-06 12:31 syzop Note Added: 0017152
2012-10-06 12:31 syzop Assigned To => syzop
2012-10-06 12:31 syzop Status acknowledged => assigned
2012-10-15 15:27 syzop Issue cloned: 0004131
2012-10-15 15:28 syzop Note Added: 0017175
2012-10-15 15:28 syzop Status assigned => resolved
2012-10-15 15:28 syzop Fixed in Version => 3.2.10-rc1
2012-10-15 15:28 syzop Resolution open => fixed
2012-10-15 15:28 syzop Note Edited: 0017175
2012-10-15 15:30 syzop Relationship added related to 0004131
2017-01-06 15:48 syzop Category module => module api