Matrix-appservice-irc: Store passwords (per-user) for keyword protected channels (+k)

[TJuberg]

This being one of my current blockers to get one of my teams moving towards matrix, it should be possible to bridge +k channels.

The channel password would have to be provided upon initiating the integration and then stored.
Ideally it would track changes observed in the IRC channel if the key changes, but leaving it as an excersise to the room admin would be fine imo.

I can also envision it being possible to tie in to ChanServ's GETKEY functionality with the prerequirement that the appservice user would have to be added with the appropriate access to the channels ACL.

[lukebarnard1]

The one block we have on this is persisting the key in a secure way I think.

[kegsay]

The bridge explicitly doesn't store channel keys, NickServ passwords, etc because we have no secure mechanism to do so.

I want to change this in the future, but we'll need to devise a better way of doing this before it can be implemented.

[kegsay]

We now have a way of storing NickServ passwords, the obvious extension now is to include a per-user dict of #channel => alleged_channel_key and consult said dict when joining channels.

[kegsay]

Updated issue to reflect what the actual feature is.

[TJuberg]

Additionally it should be possible for a plumbed channel to store the +k password on behalf of it's users, especially considering that third party integrations like gitter, slack, rss and guggy will need the password in order to not throw errors every time they are used

[kegsay]

Not going to happen. If you want to bridge to IRC from gitter, remove +k. I'm not willing to risk people calling us out for storing channel passwords for any random to use.

[TJuberg]

Why should a channel owner, who sets the key, not be allowed to store the key for the channel on the matrix side? The key is already visible to the bridge the instant the first client joins the IRC channel.
If the channel key is stored matrix side, the channel owner has made a decision to allow anyone who enters the matrix channel or anything connected to it to be able to join the irc channel, and are themselves responsible for controlling the access to the matrix channel (or gitter or slack or whatever) by setting it invite only. A simple disclaimer should be more than enough to give a warning if people want to shoot themselves in the foot by being stupid, or simply force any channel with a stored key to be invite only.

I cannot fathom why you would be worried about someone calling you out for storing what they explicitly specified that you store for their own specific channel? In the same way I'm not going to call you out for storing my Freenode Nickserv password because I gave it to you for that exact purpose.

I feel like I'm missing something obvious somewhere :\

[kegsay]

Why should a channel owner, who sets the key, not be allowed to store the key for the channel on the matrix side?

The channel owner is not necessarily the person who allowed the bridge to operate (chanop != chan owner). There is no ability for native IRC users to store the key for a channel for a set of users (or rather there is, which is don't set +k), so why should we introduce this to Matrix? It completely invalidates the security offered by +k.

A simple disclaimer should be more than enough to give a warning if people want to shoot themselves in the foot by being stupid

You are assuming that the person bridging Matrix into IRC is the same person who would be concerned that they have lost all the security of +k. Any random person can ask to bridge IRC into Matrix. The random doesn't give a shit about disclaimers saying "if you do this, you're effectively removing +k on this IRC channel". The people who do care (native IRC users) are not the ones seeing this disclaimer.

storing my Freenode Nickserv password because I gave it to you for that exact purpose

Yes, you gave it to us, with your permission and only you can access that information. That is very different to what you're proposing with +k, which is Alice providing the +k password, with Bob's (chanops) permission, and anyone can access that information (new people joining the room, bots, etc).

[Half-Shot]

I think K was pretty clear on this and we should have closed this issue a while ago.

[evoL]

Sorry, but I understood the matter differently and disagree about closing the issue.

In https://github.com/matrix-org/matrix-appservice-irc/issues/213#event-912478902, the title was changed to store passwords per user. However, what TJuberg proposed in his comment is essentially a different (sub)feature — the ability to pre-store the channel key by the bridge operator.

How I understood Kegsay's comment is that they oppose the latter, not necessarily the former. I agree about that.

In other words, storing channel keys per channel is dangerous and shouldn't be implemented, but storing the channels keys per-user is a useful feature to have. I think this issue should be reopened because of that.

[Half-Shot]

the ability to pre-store the channel key by the bridge operator.

Okay, this makes more sense. But we should open a different issue to distinguish it from this one. I can see myself allowing a PR for configuring keys on channels.