Matrix-appservice-irc: IRC invite-only channels and bans

[Ekleog]

At the moment, when a matrix-bridged user tries to join an IRC channel through the bridge, the bridge tries to make an equivalent IRC user join the channel on the IRC network. However, if the user fails to join the channel (eg. invite-only or banned user), the user will be allowed to enter the matrix room. As a consequence, if any other IRC-bridge user is allowed onto the IRC channel, the disallowed matrix user will be able to read all the messages sent to the IRC channel ; which is unexpected.

Example 1:

• Matrix users M-A and M-B join IRC channel #I_#c
• M-B is kickbanned from #I_#c via IRC
• M-B can still read all the messages in #I_#c until it is kickbanned using matrix

Example 2:

• Matrix user M-A joins invite-only channel #I_#c
• Matrix user M-B, despite never having been invited into #I_#c, can just join the corresponding matrix room and listen to all the conversations, without any IRC user ever being aware he is there, given the equivalent IRC user cannot join the IRC channel.

I hope to be clear enough.

Thank you for all the work already done!

[kegsay]

There are interesting permission impedance mismatches between Matrix and IRC in general, which you're starting to touch upon. The bridge does not currently support kick/ban mirroring but this is definitely something which will be added in the near future. Impedance mismatches immediately start though, since a Matrix ban also automatically kicks the user from the room, whereas an IRC ban does not. These are the kinds of problems that need to be worked out before this feature can be added.

With respect to +k, we don't have passwords on rooms yet so we cannot accurately map this across. It's worse than that though. The technique for joining dynamically bridged IRC channels publicly means that there is no rejection mechanism. The alias the user types in their client gets proxied through the bridge, which then tries to create a mapping (or return an existing mapping). At this point, the bridge doesn't know that the Matrix user will be unable to join because of +k. Even if it _did_ know, the AS API doesn't provide any mechanism to _reject_ the user's attempt to join the room, because it is just a simple public room alias.

That being said, the bridge can be made more conservative with its default behaviour, erring on the side of kicking users (since we can't prevent them from joining) than erring on the side of leaving them alone. This isn't a perfect solution (wonderfully racey where the user can join and potentially scrollback in the room before they get kicked, and rinse repeat), but may be an adequate stop-gap until a better solution is designed. Thoughts?

[vberger]

Regarding this specific issue, I think an interesting approach would be to add a "knock" mechanism to matrix rooms.

If a room is "invite-only", someone not in the room can send a request to be invited in it, in which case the people in the room with sufficient rights could invite they.

This would allow, in the case of bridging to mostly solve the issue I think: all bridged rooms are invite-only, and when wanting to join you need to knock, the appservice can check if the IRC chan allows you to join, and if yes then invites you to the room.

And if you receive an invite in a room you have a pending knock on, you auto-join it.

This would require to integrate this "knock" mechanism into the matrix spec, but I think it could benefit every bridge or appservice for permission handling, so it may be worth it.

What do you think?

[kegsay]

We do have plans for adding in "knock" functionality to the Matrix spec (insofar as we've even reserved the keyword in the m.room.member event), but it isn't currently a high priority for us to dedicate resources to implementing it.

Ideally we would accurately map actions like knock/kickban/password to Matrix, but your solution of working with some basic primitives like knock to implement additional mechanisms sounds good :) we just need the manpower to do so.

[kegsay]

In the vain hopes of not letting this issue fester forever, I'm going to change the aim of this issue to be:

the bridge can be made more conservative with its default behaviour, erring on the side of kicking users (since we can't prevent them from joining) than erring on the side of leaving them alone.

This will effectively mean that if a Matrix user tries to join a channel, and the IRCd returns one of a number of error codes include:

• err_banfromchan
• err_inviteonly
• etc..

then the bridge will rescind that invite/kick the matrix user from the room. This should fix the problem outlined, albeit with a bunch of caveats which I pointed out before:

racey where the user can join and potentially scrollback in the room before they get kicked, and rinse repeat

[kegsay]

Aiming to get this into the next release - 0.3.2

[kegsay]

This is now fixed as of https://github.com/matrix-org/matrix-appservice-irc/commit/72f7694576338b9c3f3a366310e0610a12eb5f25 which will be in v0.3.2

[vberger]

@kegsay does this handle the case of an user being kick/banned from a channel where they already are?

[kegsay]

Yes. When the bridge restarts with the new code, any client who is banned/used the wrong key/hasn't been invited will receive an error down their IRC connection when their virtual client tries to join it. This commit will now listen for those errors and then take appropriate action (kick them from the Matrix room).

So if they are already in the room on the Matrix-side, they will be kicked. Subsequent attempts to join will result in them being immediately kicked after joining.

[vberger]

I meant, if a matrix user is in a bridged room, talking with IRC users, and then an operator of the IRC channel decides to kickban they. Will the bridge react to that?

The commit you linked seems to only handle join errors... ?

[kegsay]

Yes, because kickbans, by definition, involve defining a banmask followed by kicking them. This means they need to rejoin the channel, and the act of rejoining will then fail with err_bannedfromchan.

[Ekleog]

I think @vberger 's question is about whether a matrix user kicked on IRC would be kicked on the matrix room, or if he would be able to stay in it until part-ing and trying to join again?

This does not seem to be handled by this commit, but based on your last message I would guess kick forwarding from IRC to matrix was already implemented?

[kegsay]

kick forwarding from IRC to matrix was already implemented

Yes, this has recently been implemented.

[Ekleog]

Thanks!