View Issue Details

IDProjectCategoryView StatusLast Update
0005960unrealircdpublic2021-07-10 10:32
ReporterValware Assigned Tosyzop  
Status resolvedResolutionfixed 
Product Version5.2.1 
Fixed in Version5.2.1.1 
Summary0005960: MD information recieved by remote server not broadcasting about itself
DescriptionSorry for the badly worded summary.

MD command for mod data doesn't get broadcasted when a server sets MD for itself.

If a services server were to send (with services SID 69L):
MD client 69L saslmechlist :PLAIN

This was not broadcasted to like it shows here:

Alice reports an exception to this "link-security" which a server can set against itself.

Tested using atheme and dalek services
Steps To ReproduceRestart anope, as anope also tries to send this MD and there is no usual message about sasl :)
TagsNo tags attached.
3rd party modules



2021-07-09 22:52

reporter   ~0022100

And alice found dis:
[Fri Jul 9 20:47:35 2021] - Remote server 'atheme.alice' tried to write moddata 'saslmechlist' of a client from ours 'atheme.alice' -- attempt blocked.


2021-07-10 10:32

administrator   ~0022101

Last edited: 2021-07-10 10:32

Thanks, fixed in and a more elaborate fix is in git.
In practice this affected admins who did not set set::sasl-server, then SASL was missing, so that was enough reason to do this dot release since we want as much as possible SASL exposure to everyone with UnrealIRCd.
Other than that, the mechlist was not shown in sasl which is really only a very minor thing.

commit d3c98c73c2e6bf380def88b239256e9f829908e1
Author: Bram Matthys <[email protected]>
Date: Sat Jul 10 08:32:22 2021 +0200

    Fix issue where saslmechlist could not be set by services server.
    This broke SASL services autodetection and also sasl=x,y,z in CAP.
    Reported by Valware in
    Of course the easiest solution would be just to set .remote_write=1
    for this, which is what I've just done for the release.
    But there seems to be a pattern here. When a server wants to write
    its own object ( writing to the MD object of we have the problem that that object is both
    "our client" and from the other server POV it is "themselves".
    On one hand you may want to allow that (eg for 'saslmechlist'), on
    the other hand a server writing its own 'certfp' sounds like a bad
    idea in principle.
    So we now add a new option for the 'self' case and make some MD
    objects use it. In fact, in the core we now have zero MD objects
    using remote_write. We keep the option available though, for example
    for k4be's geoip modules and possibly future features.
    Module API change:
    * .self_write added which allows a server to write to its own object
      ( writing to the MD object of
    * .remote_write still exists too if you want to allow remote servers
      to write to your own objects
    * Note that in all cases, servers can always write to their own
      (child) client objects.
    * The link-security MD changed from .remote_write=1 to .self_write=1
    * The salmechslist MD now has .self_write=1, this fixes the actual bug

Issue History

Date Modified Username Field Change
2021-07-09 22:15 Valware New Issue
2021-07-09 22:52 Valware Note Added: 0022100
2021-07-10 10:32 syzop Assigned To => syzop
2021-07-10 10:32 syzop Status new => resolved
2021-07-10 10:32 syzop Resolution open => fixed
2021-07-10 10:32 syzop Fixed in Version =>
2021-07-10 10:32 syzop Note Added: 0022101
2021-07-10 10:32 syzop Note Edited: 0022101