Forums Bug Reports "mIRC channel central" displays incorrect key

On Freenode, I am able to trigger this bug by setting the following modes in order, using distinct MODE commands, i.e.:

• /mode ##mIRC_bug +k test
• /mode ##mIRC_bug -k *
• /mode ##mIRC_bug +k *

mIRC now (incorrectly) thinks that the key is test, according to the "mIRC Channel Central" dialog you see here:





Incorrect display was confirmed by using a second connection to attempt to join the channel while the key was set. I used the following commands:

• /join ##mIRC_bug test
• /join ##mIRC_bug *

Only one of those commands worked, and this is how I confirmed that mIRC is displaying the wrong key in this dialog.

This issue causes worse misbehaviour on other servers such as inspIRCd, where this dialog incorrectly replaces * with the previous key when you attempt to unset... and since the key doesn't match, the IRCd software rejects it; on some server software you can't unset the "masked" key using this dialog.

Hello, this is known, check https://forums.mirc.com/ubbthreads.php/ubb/showflat/Number/173998/

Edit: while the link above helps explaining why this is happening, it doesn't justify it, this is an unrelated bug.

As explained in my reply in a previous thread, support for the hidden * key feature on some networks was added because users requested this support for it. It was added so long ago that I cannot remember which IRC network was using it. If you find out which network still supports it, please let me know. The issues you are experiencing are probably similar to what the other users were experiencing when they asked for the feature to be supported.

At the time, I considered that supporting * as a hidden key made more sense because that feature was being used by default on the IRC network and would have affected all users on all channels on that network, whereas in your example, it would only affect users on a channel where someone specifically set * as a channel key.

Server features like this are the reason I stopped supporting custom features on IRC networks and pushed for the use of numeric 005, to standardize feature support notification for clients across all networks.

In the link included in my previous post on this thread, OP commented that he can't find any network supporting this feature.

In that link you explain that mIRC does not check for any status (op etc) to hide the key, if the key received is '*', mIRC hides it.

But here mIRC receives '*' as the key but instead of hiding it, it display the previously set key.
So there is more going on in the code besides mIRC hiding the key if it's '*', and if showing the previously set key in the channel central is not a feature, it's a bug.


I agree with everything that has been said on that old thread, mIRC should never have taken the liberty to hide the key like that, it's not in the rfc and there was no way to identify if the server supported it. So if you eventually can't find network supporting that feature, I would be all for getting rid of it.

Some observations:
On all of them, mIRC behaves the same and pull the previously set key. Like I said, certainly this behavior is related to the feature which hides the key if it's '*', but that's not what is being reported here.

I connected to a few networks a moment ago and found that Undernet supports this feature. I stopped checking after that, so it's possible that some other ircds support the feature as well.


Indeed.


The whole process of IRC development since 1994 has been about taking liberties, and going beyond the RFC, both for client and server developers. That is how so many of the improvements in client and server features came about. Now that we have numeric 005 and CAP, the process should hopefully be more coordinated.

The reason that support for hidden channel keys was not limited to a particular ircd was because it was not clear which ircds were/were not supporting the feature, which was a common issue at the time.


Yes, that's intentional. See versions.txt mIRC 7.48, item 41.

I did notice recently that when doing /list, any channels which are +k show * if you're not on them. (At least in the debug output.)

E.g.

[15:29:55] <- :server.name 322 Jigsy #channel 2 :[+tnlk 17 *] topic goes here

Though this just gets truncated to [+tnlk] in actual list output...

That is a server feature for the list command.

Following up on this: after more testing, it turns out that the Undernet ircd allows you to set * as a channel key, even though it uses * as an indication to a client that the key is hidden. So a client needs to base the behaviour on whether a user is an op/non-op, which was not clear when the change was requested years ago.

I have changed support for this feature so that it is limited to the Undernet ircd (used by several networks). If you are not opped, mIRC will assume that any text provided with +k is not an actual key. If you are then opped, mIRC will send a MODE to retrieve the real key. If you are then deopped, mIRC sends a MODE to reset the key. This change will be in the next beta.

This behaviour will be dependent on the Undernet ircd version in numeric 004. I will be adding support for a new numeric 005 token HIDDENKEY that other ircds can use to enable this feature.

I updated my previous post to make it clearer.

Following up again: can someone please test the following for me on Undernet?

1) User A, connects to Undernet, joins #channel, sets channel key to 1234.
2) User B, connects to Undernet, joins #channel, receives numeric 324 +k * to indicate hidden key, as user B is not an op.
3) User A changes channel key to abcd.
4) User B receives numeric 324 +k abcd, even though they are not an op.
5) User B isues MODE, receives numeric 324 +k * to indicate hidden key.

You should test this with two copies of mIRC, one for User A and another for User B, to prevent mIRC's channel key caching from being used.

Am I making a mistake somewhere?

Yes this is exactly what happens.

-
User B will also see -k 1234 when user A changes the key to abcd

Okay. So, unless I have misunderstood the purpose of Undernet's hidden key feature, the implementation on Undernet seems to be broken. A non-op should, presumably, never receive the actual key in numeric 324.