View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004112 | unreal | ircd | public | 2012-06-25 03:08 | 2015-07-13 22:20 |
| Reporter | KindOne | Assigned To | syzop | ||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Product Version | 3.2.9 | ||||
| Summary | 0004112: Allow Normal users view ban list of channels they are not in. | ||||
| Description | In IRC land channel ops ban specific IP's and sometimes entire ISP's. Lets say someone was to "/mode #channel +b *!*@.ip.dynamic.windstream.net" because someone was being an idiot that shares the same ISP as me. This ban would also effect me, an innocent user. Now, when I try to join #channel, I can't.. cause a ban is affecting me... How am I suppose to see who set it, what is it banning me against? IP? ISP? Ident? Nick? I do not want to have to go around asking people to join a channel to see who/what banned me. Solution: Allow normal users to go "/mode #channel b" to see the ban list of channels that are not in. | ||||
| Steps To Reproduce | ((have to be a normal user)) /mode #channel +b *!*@.ip.dynamic.windstream.net ((have a few people in the channel, so it does not get destroyed when emptied)) /part #channel /mode #channel b [[can't see ban list]] | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
| related to | 0004113 | closed | [patch] remove dreamforge-isms not used by other ircds in banlist/exceptlist/invexlist querying |
|
|
The reason this is not allowed is because users can (ab)use the ability to see bans to aide in their evasion. Say I have a retard with a dynamic IP. We'll say the user is [email protected] and he's in my channel creating as much trouble as a user could possibly create. I boot him first and then set the ban because I know being a troll he'll know how to change his public IP. I then change the ban to *!~KindOne@*.dynamic.ip.windstream.net so I'm not affecting everyone on windstream. With what you suggest, KindOne can /mode #mychan b to see this ban, then change his ident to something other than KindOne (since he is not running identd, this would be a simple client change). The proper solution from a user point of view would be to find out who is op on #mychan and send a request directly to an op. This way the ban stays hidden from the user, and they can't evade! |
|
|
This is an old DreamForge-ism, which is no longer implemented even on DALnet. It needs to go, or at the least an option should be provided to make it optional. 0004113 has a patch to remove it. |
|
|
+1 |
|
|
If you could make this an option instead, then it can get in. Just have to think of an appropriate name for the setting. set::dreamforge-isms [yes/no] would not be a good name ;) I also think the current way should be the default. I can see both sides, hence making it configurable, but I agree with Stealth's view (and thus the default setting).. even if it's a bit like security by obscurity. |
|
|
I can also see this as a method of users dictating to chanops or even lame attempts at tricking chanops into (un)banning users. "Hi ChanOp, I see my buddy SpongeBob is banned .. why? .. would you unban him??" Uhm, no! I lean more towards not changing anything since IRC is and never was a democracy ;) All users need to know is if they are banned, not know everyone that is banned. Plainly said, it's none of their business. |
|
|
Reference name: set::banlist-visibility [user/voice/halfop/op/protect/owner] |
|
|
I guess it should then be either: set::banlist-visibility [remote/user/voice/halfop/op/protect/owner] (note the 'remote') or.. set::remote-banlist-visibility [yes/no] Seems the feature request is now extended to have an access level to view the banlist. I'm not sure... Reasons against: when in the channel, you still see the MODE +b, and we really have no interest in hiding these (requested several times) as it (among other reaons) requires fully rewriting the chanmode routines. So hiding would only be like half-implemented. I think it's better then not to implement the access level. Yeah... just go with the remote visibility yes/no. PS: please add any patches to this bug report, and not create a new one (as done with 0004113) |
|
|
Yeah, I threw the access level in there because I feel that if you add a new feature, might as well make it flexible so users can choose how the feature works instead of being forced to use what the developers like. If we look at commercial software, it's user centric or it's a failure. Even Linux it's self took decades to be mainstream and if you look at the most popular distributions, they are all about users and user configurable options. Just my opinion. *shrug* |
|
|
Hmmm now I read this after your comments in 0004115 I get the feeling you are somehow getting tired of UnrealIRCd (or possibly development of any software). I hope this is not the case and you will continue to make suggestions to make things better. As for your comment: as a developer and project leader I have to think ahead.. when a feature gets implemented which is half-broken (feel free to counter-argue that technical comment!) you will see users filing bugs requesting it to be 100% working, something which we cannot achieve right now nor anytime soon. You will see with other software that when they implement something that they 'know won't work correctly, IOTW: has clear inherent flaws' that.. be it samba, exim, mercurial.. or whatever software.. a while later.. could be 1 year or 2 or 4 the feature gets removed again because 'it's too ugly' and 'broken'. I have seen this many times. |
|
|
I do get tired of development at times and Unreal at times. I care quite a bit about IRC and would hate to see it fall to the way side for any preventable reason and I personally feel that IRC developers in general have failed to bring IRC into the 21st century. I mean this on both ircd and client side, so yeah I can seem a bit frustrated at times. Anyway, back on topic, "thinking ahead" is exactly why I suggest the access levels. instead of adding yes/no now and waiting for someone to ask for allowing certain chanops and not others later, might as well add it now. |
|
|
patch would be accepted for this (just the remote/not-remote thing), but no effort will be made on our part. closing. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-06-25 03:08 | KindOne | New Issue | |
| 2012-06-25 04:49 | Stealth | Note Added: 0017024 | |
| 2012-06-26 05:02 |
|
Note Added: 0017026 | |
| 2012-06-26 12:23 | dboyz | Note Added: 0017028 | |
| 2012-06-26 19:31 | syzop | Relationship added | related to 0004113 |
| 2012-06-26 19:34 | syzop | Note Added: 0017029 | |
| 2012-07-06 21:50 | katsklaw | Note Added: 0017030 | |
| 2012-07-09 22:42 | katsklaw | Note Added: 0017042 | |
| 2012-08-11 10:12 | syzop | Note Added: 0017059 | |
| 2012-08-11 10:14 | syzop | Status | new => acknowledged |
| 2012-08-11 22:26 | katsklaw | Note Added: 0017063 | |
| 2012-08-12 11:30 | syzop | Note Added: 0017065 | |
| 2012-08-14 10:02 | katsklaw | Note Added: 0017066 | |
| 2015-07-13 22:19 | syzop | Note Added: 0018489 | |
| 2015-07-13 22:19 | syzop | Status | acknowledged => closed |
| 2015-07-13 22:20 | syzop | Assigned To | => syzop |
| 2015-07-13 22:20 | syzop | Resolution | open => no change required |
