Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3893	[unreal] ircd	major	always	2010-02-28 17:35	2010-09-09 19:20
Reporter:	R-TypeEman	Platform:
Assigned To:	ohnobinki	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:	3.2.8
Product Build:		Resolution:	open
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	Firefox XPS IRC Attack
Description:	Unreal is vulnerable to the following attack: http://encyclopediadramatica.com/Firefox_XPS_IRC_Attack [^]
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0016037) syzop    2010-02-28 17:53	Is that the same as 0003862 ? And does the suggested module therein help against this ? (As you can see I was happy to do something about it, but got no feedback at all. If it's the same issue, that is.)
(0016038) syzop    2010-02-28 18:09    (edited on: 2010-02-28 18:10)	Seems so. Thanks for the heads up. I'll enhance my module a bit (it was just proof-of-concept) and make it more public ;) EDIT: btw, it should be mentioned that enabling NOSPOOF protects against this attack. Well, the clients will take up unknown connections, of course...
(0016039) R-TypeEman    2010-02-28 19:29	that module seems to do the trick thanks
(0016040) syzop    2010-02-28 19:36	Ok :) I've posted it on the website / news section: http://forums.unrealircd.com/viewtopic.php?t=6458 [^] I wasn't paying too much attention to generic IRC news for the past 6 weeks or so, and nobody informed me until now about this.. so thanks again.
(0016164) syzop    2010-07-14 17:07	ohnobinki: what do you think, I have my free module and such, I feel like it can be quite important for ircds to have... Shall I just throw it in the unreal tree? Another question is, should I call it like m_<whatever>, and make it included in commands.so too? That way, each ircd will run it. If I don't then many won't use it. Feels like a good idea..
(0016203) ohnobinki    2010-07-16 01:24	I think the module should be accepted as official (and thus shipped with unrealircd-3.2.9). I'm not sure if it's necessary to have it compiled into commands.so. 3.2.9 will have NOSPOOF enabled by default now -- perhaps that is enough. But, yes, I don't know why an IRCd wouldn't want to have this. (it doesn't look like my uncertainty here is of any help ;-) ).
(0016211) syzop    2010-07-16 14:52	hehehe ok, let's put it in then. and yeah link it in commands. perhaps name it m_something too so loadmodule m_*.so will include them if someone doesn't use commands.so. still, have to think about the default settings. some users reported an annoying amount of notices regarding bots (webspiders) going to their ircd. hmmmm.
(0016353) chotaire    2010-09-09 15:28	Same here, why is this important module not in the modules database?
(0016354) ohnobinki    2010-09-09 15:31	Because the modules ``database'' is un-modifiable.
(0016356) syzop    2010-09-09 19:20	ARGH.. same note as the other bug.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3720	[unreal] ircd	major	always	2008-08-17 18:57	2010-09-09 19:19
Reporter:	fez	Platform:	x86
Assigned To:	syzop	OS:	Linux Mandrake
Priority:	normal	OS Version:	2.6.24.2-1fez
Status:	assigned	Product Version:	3.2.7
Product Build:		Resolution:	reopened
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	ULines and Server can set channel mode +z when insecure users are present causing an "invalid state" of security
Description:	M_MODE does not do any checking to see if insecure users are on a channel when setting mode +z, IF the setter of the mode is ULined or a server. This means that, for example, I could set MLOCK +z on a channel (via services), then a new (insecure) user could join the empty channel, and services would set mode +z, and the user would remain on the channel. Since M_SJOIN enforces +z rules, in the case of a netsplit/netrejoin, so, too, should m_mode enforce +z rules even if the MODE command comes from services/uline/server.
Steps To Reproduce:
Additional Information:	Here is the fix: I forget what is the diff command to create the appropriately readable patch. ********** src/modules/m_mode.c line 829 --OLD (from 3.2.7 release)--       case MODE_ONLYSECURE:           notsecure = 0;           if (what == MODE_ADD && modetype == MODE_ONLYSECURE && !(IsServer(cptr) || IsULine(cptr)))         {           for (member = chptr->members; member; member = member->next)           {             if (!IsSecureConnect(member->cptr) && !IsULine(member->cptr))             {             sendto_one(cptr, err_str(ERR_CANNOTCHANGECHANMODE),                    me.name, cptr->name, 'z',                    "all members must be connected via SSL");             notsecure = 1;             break;             }           }           member = NULL;           /* first break nailed the for loop, this one nails switch() */           if (notsecure == 1) break;         }         goto setthephuckingmode; ********** src/modules/m_mode.c line 829 --FIXED--       case MODE_ONLYSECURE:           notsecure = 0;         // modified by fez, so if servers set onlysecure mode, it honors it and removes insecure users           if (what == MODE_ADD && modetype == MODE_ONLYSECURE)         {             if (IsServer(cptr) || IsULine(cptr))                     {                 kick_insecure_users(chptr);             }             else             {                 for (member = chptr->members; member; member = member->next)                 {                     if (!IsSecureConnect(member->cptr) && !IsULine(member->cptr))                     {                         sendto_one(cptr, err_str(ERR_CANNOTCHANGECHANMODE),                            me.name, cptr->name, 'z',                            "all members must be connected via SSL");                         notsecure = 1;                         break;                     }                   }                 member = NULL;                 /* first break nailed the for loop, this one nails switch() */                 if (notsecure == 1) break;             }         }         goto setthephuckingmode;
System Description
Attached Files:

Notes
(0015362) fez    2008-08-17 23:02	CAVEAT In this scenario, although "secure" channels are now properly safeguarded (aside, of course, from having to trust server admins that server-server links are secure), it does raise one possible problem. If a user has their client to "auto-rejoin-on-kick", and they join an empty channel, and services sets the channel to secure, the server will kick the user from the channel, causing the now empty channel to be destroyed, allowing the user to rejoin the empty channel again. In other words, it can create a server-client join-kick flood battle. For this I recommend configuring services to remain present in any channels that are set to secure. I still recommend implementing the afformentioned patch, though. Please discuss....  - Eric / fez
(0015363) fez    2008-08-17 23:48	One possibility We could have "insecure" kicks caused by MODE +z to result in PART messages going to the users instead of kick messages. Insecure kicks cause by SJOIN would still result in KICK messages. Or perhaps it could alternate between KICK and PART, or perhaps it could be a configurable setting.... In any case, something clearly needs to be done, cause it should not be possible to create a +z channel with non-secure users on it. I'll test it out by duplicating kick_insecure_users() as part_insecure_users(), and trying it on irc://chi.wrongway.org [^] Peace
(0015365) fez    2008-08-18 05:40    (edited on: 2008-08-27 01:38)	FIX To implement the PART idea, where Servers/Ulines issuing MODE +z on channels with insecure users cause the server to send "PART" messages to insecure users rather than KICK messages, you must make these modifications: 1. Apply the simple change I noted in the original post, changing kick_insecure_users to part_insecure_users, like so: ********** src/modules/m_mode.c line 829 --OLD (from 3.2.7 release)--       case MODE_ONLYSECURE:         notsecure = 0;         if (what == MODE_ADD && modetype == MODE_ONLYSECURE && !(IsServer(cptr) || IsULine(cptr)))         {           for (member = chptr->members; member; member = member->next)           {             if (!IsSecureConnect(member->cptr) && !IsULine(member->cptr))             {               sendto_one(cptr, err_str(ERR_CANNOTCHANGECHANMODE),                 me.name, cptr->name, 'z',                 "all members must be connected via SSL");               notsecure = 1;               break;             }           }           member = NULL;           /* first break nailed the for loop, this one nails switch() */           if (notsecure == 1) break;         }         goto setthephuckingmode; ********** src/modules/m_mode.c line 829 --FIXED--       case MODE_ONLYSECURE:         notsecure = 0;         // modified by fez, so if servers set onlysecure mode, it honors it and removes insecure users         if (what == MODE_ADD && modetype == MODE_ONLYSECURE)         {           if (IsServer(cptr) || IsULine(cptr))           {             part_insecure_users(chptr);           }           else           {             for (member = chptr->members; member; member = member->next)             {               if (!IsSecureConnect(member->cptr) && !IsULine(member->cptr))               {                 sendto_one(cptr, err_str(ERR_CANNOTCHANGECHANMODE),                   me.name, cptr->name, 'z',                   "all members must be connected via SSL");                 notsecure = 1;                 break;               }             }             member = NULL;             /* first break nailed the for loop, this one nails switch() */             if (notsecure == 1) break;           }         }         goto setthephuckingmode; 2.modify include/h.h, like so: ********** include/h.h line 784 --OLD (from 3.2.7 release)-- extern void kick_insecure_users(aChannel *); ********** include/h.h line 784 --FIXED-- extern void kick_insecure_users(aChannel *); extern void part_insecure_users(aChannel *); 3. in src/s_misc.c, at the bottom of the file, insert: ********** src/s_misc.c at bottom of file: /** Parts all insecure users on a +z channel */ void part_insecure_users(aChannel *chptr) {     Member *member, *mb2;     aClient *cptr;     char *comment = "Insecure user not allowed on secure channel (+z)";          for (member = chptr->members; member; member = mb2)     {         mb2 = member->next;         cptr = member->cptr;         if (MyClient(cptr) && !IsSecureConnect(cptr) && !IsULine(cptr))         {             RunHook4(HOOKTYPE_LOCAL_PART, cptr, &me, chptr, comment);             if ((chptr->mode.mode & MODE_AUDITORIUM) && is_chanownprotop(cptr, chptr))             {                 sendto_chanops_butone(cptr, chptr, ":%s!%s@%s PART %s :%s",                     cptr->name, cptr->user->username, GetHost(cptr), chptr->chname, comment);                 sendto_prefix_one(cptr, &me, ":%s!%s@%s PART %s :%s",                     cptr->name, cptr->user->username, GetHost(cptr), chptr->chname, comment);             }             else             {                 sendto_channel_butserv(chptr, &me, ":%s!%s@%s PART %s :%s",                     cptr->name, cptr->user->username, GetHost(cptr), chptr->chname, comment);             }             sendto_serv_butone_token(&me, cptr->name, MSG_PART, TOK_PART, "%s :%s", chptr->chname, comment);             remove_user_from_channel(cptr, chptr);         }     } } 5. recompile. If you're on win32, you'll have to re-make SYMBOLFILE. 6. viola...
(0015366) fez    2008-08-18 05:47	I have found the PART idea works nicer than the KICK idea for this particular purpose. It avoids the dreaded kick/rejoin war in empty channels with mlock +z activated. An alternative solution would be to make services do the work, and have ChanServ join the channel making it non-empty, setting mode +z, and explicitly kicking users, then perhaps leaving the channel after a time limit. Nevertheless, this way, the ircd can actually provide some assurance that secure channels only have secure users. Another option to consider down the line would be a config option to have secure channels ensure secure links, but that would be very difficult to implement as leafs more than 1 hop away do not even report whether they are securely linked or not; only that they exist. I think this is an acceptable comprimise -- avoiding chanserv mlock +z causing mode +z to be set on channels with insecure users without causing possible kick/join wars. Please discuss
(0015367) fez    2008-08-18 05:54	you can test it at chi.wrongway.org #securetest
(0015375) Bricker    2008-08-26 23:13    (edited on: 2008-08-26 23:28)	Um, helllloooooo! This was my f*ing idea like months ago! EDIT This was discussed a LONG time ago, like....3.2.something like 2 years ago, i thought we came to the conclusion that it needed fixed and was, maybe I'm wrong. *shrugs*
(0015380) fez    2008-08-27 00:35	Well, now you have a fix right here. Hope it gets incorporated into 3.2.8. - fez personally i like using part_insecure_users for the MODE +z method, though KICK may be just as good (possibly causing KICK/JOIN floods). Another option would be to cause a temporary (e.g. 2 second) SHUN on users who are affected by MODE +z KICK's to prevent their auto-rejoin from functioning. This may be a better option.
(0015381) fez    2008-08-27 01:23	I have been source diving and this is what I have determined: kick_insecure_users is defined in src/s_misc.c shuns are executed by the function m_tkl_line in file src/modules/m_tkl.c this means that modifying kick_insecure_users to take in a SHUN parameter would make s_misc.c dependent on the module M_TKL, which may or may not be loaded. This won't compile. The other option is to move kick_insecure_users into another file such as M_TKL.c, M_SJOIN.c or M_MODE.c, but this would again cause dependency issues as M_SJOIN and M_MODE would be dependent on M_TKL. The only way to resolve this, essentially, is to move the SHUN system (and thus, the entire TKL system) into the core of the IRCd to prevent dependency issues. An alternative (just as difficult), would be to make M_SJOIN and M_MODE check for the M_TKL module at run-time, but that would require something like making an API for modules to load other modules, still a big mess. Perhaps if there was some sort of generic dummy TKL interface built-in to the IRCd, then M_TKL could just implement it, that would be better, but also still difficult. In conclusion, I recommend using the part_insecure_users method on MODE +z, and perhaps adding a config-file or compile-time directive, like PART_ON_ULINE_MODE_SECURE. That's the easiest "neat" answer for this problem... Please discuss  - fez
(0015382) fez    2008-08-27 06:25	REVISED FIX Here is yet another idea!!! I have edited the fix described above to act slightly differently: 1. only send PART if there is one user on the channel (e.g., the channel was just created), otherwise, send the mass KICK (e.g., if the channel is already populated and the owner just did something like /chanserv set #chan mlock +z). 2. when PART is sent, also send ERR_ONLYSECURECHAN so that the client actually gets two messages, in case (as in the case of mIRC) the PART reason is not seen. I have tested this with mIRC and irssi and it seems to work well, without baffling users. To implement this patch, do the following: 1. modify src/modules/m_mode.c, like so: ********** src/modules/m_mode.c line 829 --OLD (from 3.2.7 release)--       case MODE_ONLYSECURE:         notsecure = 0;         if (what == MODE_ADD && modetype == MODE_ONLYSECURE && !(IsServer(cptr) || IsULine(cptr)))         {           for (member = chptr->members; member; member = member->next)           {             if (!IsSecureConnect(member->cptr) && !IsULine(member->cptr))             {               sendto_one(cptr, err_str(ERR_CANNOTCHANGECHANMODE),                 me.name, cptr->name, 'z',                 "all members must be connected via SSL");               notsecure = 1;               break;             }           }           member = NULL;           /* first break nailed the for loop, this one nails switch() */           if (notsecure == 1) break;         }         goto setthephuckingmode; ********** src/modules/m_mode.c line 829 --FIXED--       case MODE_ONLYSECURE:         notsecure = 0;         // modified by fez, so if servers set onlysecure mode, it honors it and removes insecure users         if (what == MODE_ADD && modetype == MODE_ONLYSECURE)         {           if (IsServer(cptr) || IsULine(cptr))           {             if (chptr->users == 1)               part_insecure_users(chptr);             else               kick_insecure_users(chptr);           }           else           {             for (member = chptr->members; member; member = member->next)             {               if (!IsSecureConnect(member->cptr) && !IsULine(member->cptr))               {                 sendto_one(cptr, err_str(ERR_CANNOTCHANGECHANMODE),                   me.name, cptr->name, 'z',                   "all members must be connected via SSL");                 notsecure = 1;                 break;               }             }             member = NULL;             /* first break nailed the for loop, this one nails switch() */             if (notsecure == 1) break;           }         }         goto setthephuckingmode; 2.modify include/h.h, like so: ********** include/h.h line 784 --OLD (from 3.2.7 release)-- extern void kick_insecure_users(aChannel *); ********** include/h.h line 784 --FIXED-- extern void kick_insecure_users(aChannel *); extern void part_insecure_users(aChannel *); 3. in src/s_misc.c, at the bottom of the file, insert: ********** src/s_misc.c at bottom of file: /** Parts all insecure users on a +z channel */ void part_insecure_users(aChannel *chptr) {     Member *member, *mb2;     aClient *cptr;     char *comment = "Insecure user not allowed on secure channel (+z)";          for (member = chptr->members; member; member = mb2)     {         mb2 = member->next;         cptr = member->cptr;         if (MyClient(cptr) && !IsSecureConnect(cptr) && !IsULine(cptr))         {             RunHook4(HOOKTYPE_LOCAL_PART, cptr, &me, chptr, comment);             if ((chptr->mode.mode & MODE_AUDITORIUM) && is_chanownprotop(cptr, chptr))             {                 sendto_chanops_butone(cptr, chptr, ":%s!%s@%s PART %s :%s",                     cptr->name, cptr->user->username, GetHost(cptr), chptr->chname, comment);                 sendto_prefix_one(cptr, &me, ":%s!%s@%s PART %s :%s",                     cptr->name, cptr->user->username, GetHost(cptr), chptr->chname, comment);             }             else             {                 sendto_channel_butserv(chptr, &me, ":%s!%s@%s PART %s :%s",                     cptr->name, cptr->user->username, GetHost(cptr), chptr->chname, comment);             }             sendto_one(cptr, err_str(ERR_SECUREONLYCHAN), me.name, cptr->name, chptr->chname);             sendto_serv_butone_token(&me, cptr->name, MSG_PART, TOK_PART, "%s :%s", chptr->chname, comment);             remove_user_from_channel(cptr, chptr);         }     } } 5. recompile. If you're on win32, you'll have to re-make SYMBOLFILE. Note: you may have to clean up the tab stops from spaces. my copy/paste function didn't seem to preserve it correctly. I think this is the most manageable solution thus far... Please discuss...
(0015427) Strawberry_Kittens    2008-11-23 20:49	>>// modified by fez, so if servers set onlysecure mode, it honors it and removes insecure users I believe this was suggested by another user at one point and was agreed that removing all the insecure users was to risky, some op could just mlock +z and easily take over the channel, or during a netsplit some random user could acquire op on a server, Set +z, then when they relinked & +z went to all the servers, he/she could easily take over the channel. It would be better to just remove +z if there are insecure users in the channel.
(0015428) fez    2008-11-23 22:11	It is true that it is possible to "takeover" a channel by setting mode +z on it when there insecure users present. This is possible even without my patch. There are a few things to consider here. 1. we assume that if a user has ops on a channel then they should be allowed to set +z/-z on it. 2. if a user acquired ops by rejoining an empty chan during a netsplit, then set +z, the +z will be removed anyway thanks to the timestamp protocol. (channels with younger timestamps do not have their modes merged with equivalent channels with older timestamps; rather their modes are simply removed). 3. although, yes, simply removing mode +z if there are any insecure users present will alleviate the issue of "secure desynching", another problem then arises. Essentially, a channel could be made -z, even though secure users joined it with the assumption that it was secure. there would be a trust violation here... Although it may not be fair to assume that once a channel is +z, it will remain that way, there should at least be some guarantee that -z can only be set by human interaction... 4. finally, there is the practical issue here. If you're setting mode -z after a ULINE set +z, then there are two problems: first, the assumption that ULINES can set any mode they want has been broken and proves inconsistent. Unreal was specifically designed to let ULINEd servers have special control without being contradicted, because those contradictions generally leads to problems. Secondly, an example of such a problem. If you set chanserv MLOCK +z on a channel, and then unreal overrides it because there are insecure users on the channel, then you trigger a war between (ULINEd) services setting mode +z, and unreal setting mode -z. This mode war would be even worse than the initial problem of a possible kick/join flood. Especially for this last practical reason, I cannot agree with the recommendation that +z should simply be overriden if the channel contains insecure users. I might be inclined to agree with that implementation *IF* the originator of the +z command was *not* ULINEd, but that does not resolve the rather important original issue of what to do if a ULINE sends mode +z to a channel with insecure users.
(0016022) syzop    2010-02-13 14:19	I would suggest everyone who considered this to take a deep breath, look over it again. I mean, just look at it, can you see how ugly and intrusive this patch is?? Perhaps it started as a good idea, but if you read over it again, you should see it.. I hope. It's definitely not something I'll implement. As for MLOCK ignoring the rules of +z, which seems to be the issue. Simple solution: the services coders should fix this. If you're not happy with their solution, then fix it in a different way (in services). I really don't see any reason for us to fix services bugs.
(0016026) fez    2010-02-16 05:15    (edited on: 2010-02-16 06:38)	Sorry to reopen this. I have implemented the fix as a module since it seems no one cares about this. See http://wrongway.org/mods/f_ulinessl.zip [^] for the fix. It adds a config setting to specify if you want a user to be kicked or parted if a channel contains only insecure users, as set::uline-secure-action. Feel free to comment on it's functionality. Peace  - fez
(0016027) Stealth    2010-02-16 05:26	I really do think this should be in the core... An issue like this can go back and fourth between users and developers and carry on for ages (and this one has been around for quite some time). Users want to know their channel is secure, especially after a services or network failure... and no one wants to implement it. IRCd developers say it isn't their problem because services should be able to determine what modes can be set when and what modes require what conditions. Services developers say it's up to the IRCd to enforce the modes set on a channel. Unreal has the protocol where anything a ULine sends gets done, which doesn't help this situation at all. Someone needs to step up and be the better part of this and just implement some kind of check. Either way, users will be booted from a channel, so it doesn't really matter who does it in the end, it just needs to happen. I think it should be the IRCd. > can you see how ugly and intrusive this patch is?? Ugly, perhaps. Intrusive? I think that's a stretch. It may not be pretty, but if you think about the number of situations this will actually happen in everyday IRC usage it's something that would make many people with secure channels a little happier, especially during network or service failure. As I see it, there are a few ways this can happen. - Users get KICKed from the channel with the friendliest reason we can come up with. - Users get a nice gentle PART from the channel (with reason). - We implement mode +Z that is set until all the non-SSL users have left, while disallowing non-SSL users to join. With the last non-SSL user, the channel is set to +z. - We implement mode +Z that is set along with +z to let people know there are insecure users still in the channel. (+Z is unset when the last one leaves, -Z will not be accepted from U:Lines) - We ignore the fact that +z was set (unless it can be). - We don't send channel messages to non-SSL users, as well as not allowing them to send messages to the channel. (Which leaves them in the channel, just unable to participate)
(0016028) syzop    2010-02-16 18:51	I honestly am surprised that you don't understand how ugly and bad the previously proposed hacks are. Anyway... I'm glad you came with a better idea, +Z :P. Though, I heard you might have taken it from another ircd? If so, do you know which one? The +Z idea makes sense. However, I would rather implement it like: * Keep +z like it is now, "Only clients on a Secure (SSL) Connection may join". This is how it's already documented, note the 'may join' and NOT 'only clients on a SSL connection are on the channel'! * +Z will be set when all users on the channel are secure. So that means: * /mode #chan +z, and everyone is secure, +zZ will be set. * /mode #chan +z, and not everyone is secure, +z will be set.   * once everyone on the channel is secure, set +Z * If for some reason (remote) insecure people join, set -Z * For any +Z/-Z mode switching there'll be a server notice, to say why it is being done, and what it means. Same for when +z gets set but not +Z. That sounds like a better idea than transforming a z into a Z or doing it the other way around. That way we can also get rid of the kick_insecure_users(). Well, partially, as we'll keep it for channels where a lower TS (+z) wins from a higher TS (not +z). But it can be removed from merge (equal TS). I don't know why I did it on merge, looking back and reading logs I probably just didn't think of it, but it's pretty stupid, merge should merge both sides, and now the one without +z is a 'loser', this violates the principle of 'merge'. If we do this +Z thing, then we could also allow +z to be set with non-SSL users present. Now, sure, you can say "users might accidentally set +z and lock themselves out", but this is no argument for me, as there are many ways (and channel modes) to do that. As for compatibility, it's an addition of a paramless channel mode so is ok to add. And software like services shouldn't care much about it, like they don't even have to implement support for it. [*] 'secure' in this context obviously means that the people who are on it are on SSL/TLS (umode +z), nothing else.
(0016029) fez    2010-02-16 19:12	In that case you might as well remove all the code that prevent +z being set when insecure users are present. +z should be settable at any time, since it offers no assurances.
(0016030) syzop    2010-02-16 20:57	yeah, like I said.. 'If we do this +Z thing, then we could also allow +z to be set with non-SSL users present.'
(0016031) Stealth    2010-02-16 23:10	This post comes from the trolling side of me, but has some interesting questions/points about questions/topics that have come up in the past... - How will +Z be handled over server links? Will it be up to each local IRCd to set, or will the IRCd with the last non-SSL user be responsible for setting it? - What happens when a crappily coded ULine wants to set +Z on a channel with non-SSL users? Will they be parted, or will the mode simply be denied. - What about SSL users on non-SSL links? (I am sure this is rare, but a valid point when trying to create truly secure channels)     - Will they be allowed to join even though the link between servers is plaintext?     - Will -Z be set until all the SSL users from the non-SSL link leave? I know #3 will probably create some confusion over users and possibly expose some network vulnerability in identifying some of the server routing and which links are plaintext, but unfortunately it's a problem unless you simply -Z the channel and not tell anyone, but then people will whine that all the users in the channel are secure and +Z isn't working... Oh, and I don't know which other IRCd does the +Z thing (or much of the details behind it), all I remember is reading about it somewhere and thinking that wasn't such a bad idea.
(0016032) fez    2010-02-17 01:19	+Z can all be handled locally. This will alleviate issues where servers (or services) falsely send +Z requests. Generally speaking the server should ignore all requests to set +Z and only set them if and when the server thinks it's appropriate. I wrote a function count_secure_users in the module linked in my above post) which could easily be converted to count_insecure_users, so a few hooks on PART, QUIT or KICK could simply ask: is channel +z? Are insecure users present? Is channel +Z? Set/unset +Z as necessary. This could also be done at remove_user_from_channel() (or the like). If performance is an issue, struct Channel could include a member like secureusers (similar to Channel::users) So who is going to implement this? As for ensuring that server-server links are SSL, I reckon that for simplicity's sake we simply rely on the server administrators to ensure that inter-server links are secure. Thinks would be more complicated if +Z could only be set when all server-server links are SSL. For example, what if server A-B is SSL, and B-C is non-ssl, and a channel exists which has exactly 5 SSL users from A and 5 SSL from B (and none from C). Should +Z be rejected because the irrelevant B-C link is non-SSL? Then again... what if B and C are both on the same machine connected via localhost? Then their being SSL is irrelevant. No, I definately say let's leave the server-server link security up to the admins. If it's really a problem perhaps a channel notice could be generated saying link A-B is non SSL.
(0016033) Stealth    2010-02-17 01:51	I like the idea of leaving the server linking up to the admins, however this will generate some concern with knowledgeable users. If we do a notice to warn users, we should perhaps not disclose link specifics and make the notice like "NOTICE @#Channel :All users in this channel are connected with SSL, however channel messages may travel in plain text between servers.", as well as send a onotice such as "Warning -- #Channel has +Z, however the link between serverA.example.com and serverB.example.com is not secure." Of course this would only be if there are users from both sides of the insecure link in the channel. (perhaps the onotice can be sent to the eyes snomask)
(0016034) Stealth    2010-02-17 01:55	Note: I do understand that more notes may be messy, annoying, and unwanted by many admins, so there should probable be a set option for disabling them (set::options::no-ssl-onotices or something)... I do suggest more notices with the hopes that Unreal can be one of the few IRCds that expresses concerns about connection security. There are many features Unreal *doesn't* have for the whole reasoning of "false sense of security", so why not add a couple things to keep people from having such a false sense :)
(0016035) syzop    2010-02-17 11:33	I'll do it. Though, not this week, perhaps next.. we'll see. It's something I'd like to have in 3.2.9. As for taking serverlinks into account, I've thought about it, but I agree with fez here. We must leave this up to the server admins. Other servers can't see if far servers are SSL linked, and the localhost / safe localnet issue also came up in my mind. Let's not make this overcomplicated.
(0016052) driew    2010-04-03 12:17    (edited on: 2010-04-03 12:20)	The other issue that comes to mind, is what do you do with +S users that aren't secure. I have yet to see a ULine use secure links (I usually link them locally, then the ircd is ssl enabled, to avoid this) but the service bots won't have +z. So does the IRCD ignore the fact that ulined hosts aren't ssl? Again, do we follow the "Allow ULines to do anything" mentality, since some ulines probably aren't good to have non-ssl. Such as stats, and where the stats are stored (plain text databases, on a potentially exploitable system since it's not hidden from users) I personally would go with, (pseudo) if (LastInsecureUser(cptr) && IsSecure(cptr) && !IsULine(cptr)) set_+Z; Just ignoring if a ULine is on the channel, and letting it set +Z. Also, what happens when an Oper with can_override forces himself in? Do you continue to leave it +Z, or do you at that point, -zZ the channel or just -Z the channel? As currently, it let's you override with /join #channel override; and then it sets -z (which is interesting, since a +z on mlock, resets it and then the ircop is in a +z channel thanks to the ULine). Will the /join #channel override as a key, only unset -Z, or will the override even be required (once you /invite)? I think with this implementation, it's safe to remove the /join #channel override requirement, once an /invite has been ensued; and then just -Z but leave it +z for everyone else (the oper can then override a -z if required) Discuss?
(0016057) fez    2010-04-03 18:47	+S users (services) joining secure channels would be along the lines of leaving it to admins to set up "secure" (either ssl or localhost-localhost) server links, and letting them worry about that. I wouldn't worry about +S users joining +z channels since services are usually linked via localhost or at least LAN.
(0016058) Stealth    2010-04-03 18:56	> The other issue that comes to mind, is what do you do with +S users that aren't secure. > I have yet to see a ULine use secure links (I usually link them locally, then the ircd is ssl enabled, to avoid this) but the service bots won't have +z. > So does the IRCD ignore the fact that ulined hosts aren't ssl? This has been discussed many times. Sure there's no service package that supports SSL, but I have yet to see a sane network configuration where the services connection actually reaches a network where it would be vulnerable to eavesdropping. Most services are linked with a loopback connection (localhost, or the box's own IP). Also, for those netadmins with users that insist on linking servers over the internet, and are also concerned about keeping everything encrypted they would probably use sTunnel, or hack their own SSL connectivity into their services. This was also explained by Syzop's comment saying that keeping links secure is entirely up to the admin and the software will not warn/deny users to stop confusion. > Also, what happens when an Oper with can_override forces himself in? Do you continue to leave it +Z, or do you at that point, -zZ the channel or just -Z the channel? Opers with OperOverride using plaintext connections have never been able to force themselves into a +z channel without forcing -z on the channel. This will remain the same. As for services MLOCKing +z, +z will be readded but +Z will not be. +Z should ALWAYS be removed when -z is set.
(0016059) driew    2010-04-03 19:02    (edited on: 2010-04-03 19:04)	>Opers with OperOverride using plaintext connections have never been able to force themselves into a +z channel without forcing -z on the channel. Well, they don't explicitly have to set -z, the ircd does it for them (/invite, then /join #chan override). The question is, will the ircd set -z, or does it respond the same as if +z was set while a non-ssl user was on the channel. (it would simply set -Z, but leave +z) Same as, what happens when a user is /sajoin'ed into a +zZ channel, does it remove both -z and -Z, or just the -Z leaving it +z? To me, it makes sense to change the current behavior of setting -z, and instead leave +z (so new users can't join, using syzops proposal), and just setting -Z. Edit: Though, at this point. I think we are all kind of on the same page, I'm just saying it differently..
(0016352) chotaire    2010-09-09 15:21	Why is this module not in the modules database? People do care, thanks for the module Fez!
(0016355) syzop    2010-09-09 19:19	For tons of reasons, but nr 1 being that this will be solved in 3.2.9 itself!

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3958	[unreal] installing	major	always	2010-09-08 16:29	2010-09-08 17:39
Reporter:	chotaire	Platform:	x86
Assigned To:	syzop	OS:	QNX
Priority:	normal	OS Version:	6.5.0
Status:	resolved	Product Version:	3.2.9
Product Build:	CVS 877	Resolution:	fixed
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	./Config does not forward --enable-inet6 parameter to configure process
Description:	There is a HOT new issue with CVS regarding IPv6, I realize it cannot bind stream sockets to IPv6 addresses anymore, while this worked fine with 3.2.8.1. IPv6 was select during ./Config. I am adding log entries: [Wed Sep 8 16:02:49 2010] - setsockopt(IP_OPTIONS) irc.example.com[]:Invalid argument [Wed Sep 8 16:02:49 2010] - Error binding stream socket to IP 2001.0.0.0 port 7100 - irc.example.com[]:Can't assign requested address [Wed Sep 8 16:03:51 2010] - setsockopt(IP_OPTIONS) irc.example.com[]:Invalid argument [Wed Sep 8 16:03:51 2010] - Error binding stream socket to IP 2001.0.0.0 port 7100 - irc.example.com[]:Can't assign requested address While double-checking the ./configure progress I realize that eventhough IPv6 was enabled by default, --enable-inet6 was not added to the configure parameters (!). Adding it to the extra parameters in ./Config fixes the issue and IPv6 is compiled in properly. ziplinks are not affected by this bug. I haven't tested remote includes.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0016345) syzop    2010-09-08 17:14    (edited on: 2010-09-08 17:15)	I think I misread configure.ac, try reverting this patch (for ./Config), and see if it solves things: http://cvsweb.unrealircd.com/cgi-bin/cvsweb/unreal/Config.diff?r1=1.1.1.1.4.1.2.58.2.24;r2=1.1.1.1.4.1.2.58.2.25 [^]
(0016346) syzop    2010-09-08 17:18	Hm, yeah, that must be the issue, fixed in .878: - Reverted an IPv6/Config fix I did on July 17. Reported by chotaire (0003958).
(0016348) ohnobinki    2010-09-08 17:25	syzop: Not directly pertaining to this bug, but this issue and similar ones could be avoided if the code looked like: if [ "$INET6" = "1" ]; then     ARG="$ARG--enable-inet6 " else     ARG="$ARG--disable-inet6 " fi May I change ./Config to do this for all ./configure options?
(0016349) syzop    2010-09-08 17:39	Why would we want to add X options when they have no effect? :P Actually it was all working ok, until you decided to set different defaults... Perhaps another time, but not now.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3955	[unreal] installing	block	always	2010-09-07 17:02	2010-09-08 17:18
Reporter:	chotaire	Platform:	x86
Assigned To:	ohnobinki	OS:	QNX
Priority:	normal	OS Version:	6.5.0
Status:	resolved	Product Version:	3.2.8
Product Build:	3.2.8.1	Resolution:	fixed
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	Modifications to source necessary to compile on QNX 6.5.0
Description:	The following modifications were necessary to successfully compile Unreal 3.2.8.1 on QNX 6.5.0, as seen by compile errors: ----------------------- gcc -I../include -I/home/irc/ircd-nassau/extras/regexp/include -I/home/irc/ircd-nassau/extras/c-ares/include -L../extras/c-ares/lib -pipe -g -O2 -funsigned-char -fno-strict-aliasing -Wno-pointer-sign -DZIP_LINKS -export-dynamic -DFD_SETSIZE=900 -c timesynch.c In file included from ../include/common.h:46,                  from ../include/struct.h:43,                  from timesynch.c:21: ../include/sys.h:47:23: error: sys/errno.h: No such file or directory make[1]: *** [timesynch.o] Error 1 make[1]: Leaving directory `/home/irc/ircd-nassau/src' make: *** [build] Error 2 I changed <sys/errno.h> to <errno.h> in include/sys.h and it will continue compiling just fine. ----------------------- gcc -I../include -I/home/irc/ircd-nassau/extras/regexp/include -I/home/irc/ircd-nassau/extras/c-ares/include -L../extras/c-ares/lib -pipe -g -O2 -funsigned-char -fno-strict-aliasing -Wno-pointer-sign -DZIP_LINKS -export-dynamic -DFD_SETSIZE=900 -c s_bsd.c s_bsd.c: In function 'init_sys': s_bsd.c:644: error: too many arguments to function 'setpgrp' make[1]: *** [s_bsd.o] Error 1 make[1]: Leaving directory `/home/irc/ircd-nassau/src' make: *** [build] Error 2 I change line 644 to:         (void)setpgid(0,(int)getpid()); It's also possible to change line 644 to:         (void)setsid();      ----------------------- After which it will compile just fine without any warnings.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0016331) ohnobinki    2010-09-07 17:40	- Don't use sys/errno.h, as it's not POSIX and breaks on QNX-6.5.0. (0003955) Thanks very much for the report :-).
(0016333) chotaire    2010-09-07 18:12	One issue missed during resolve.
(0016339) syzop    2010-09-08 13:05	I see: #if defined(HPUX) || defined(_SOLARIS) || \     defined(_POSIX_SOURCE) || defined(SVR4) || defined(SGI) || defined(OSXTIGER)         (void)setsid(); #else         (void)setpgrp(0, (int)getpid()); #endif What exact change do you suggest? a defined(..QNXSOMETHING..) added to the first #if ? I've now added an || defined(__QNX__) Could you check that fixes it? : #if defined(HPUX) || defined(_SOLARIS) || \     defined(_POSIX_SOURCE) || defined(SVR4) || defined(SGI) || \     defined(OSXTIGER) || defined(__QNX__)         (void)setsid(); #else         (void)setpgrp(0, (int)getpid()); #endif Thank you very much for testing QNX by the way, glad to hear it works after these few adjustments :)
(0016341) chotaire    2010-09-08 13:47	I'll check CVS shortly. If there is any remaining issues regarding QNX (also concerning the fixtimer issue), I will let people know. As for the timing issue, I had already patched the source myself (bad hack though but it works) and you might enjoy to know that there is now one live IPv6+SSL unrealircd server running on QNX (never heard of any ircd on QNX before). Implementing the IPv6 stack was quite a headache though but after all it works just great. I love QNX.
(0016342) chotaire    2010-09-08 16:26	I have just checked out the latest CVS version, verified that all three reported issues were patched and give it a shot. [A] COMPILATION Compilation went through of the box. It might be noteworthy to mention that I have to select <1000 file descriptors (or sockets) during ./Config on QNX6, because only 1000 is supported out of the box, but people would find out anyway once they start the ircd for the first time. [B] SKIPPED CONFIGURE PARAMETER FOR IPv6 There is a HOT new issue with CVS regarding IPv6, I realize it cannot bind stream sockets to IPv6 addresses anymore, while this worked fine with 3.2.8.1. IPv6 was select during ./Config. I am adding log entries: [Wed Sep 8 16:02:49 2010] - setsockopt(IP_OPTIONS) irc.example.com[]:Invalid argument [Wed Sep 8 16:02:49 2010] - Error binding stream socket to IP 2001.0.0.0 port 7100 - irc.example.com[]:Can't assign requested address [Wed Sep 8 16:03:51 2010] - setsockopt(IP_OPTIONS) irc.example.com[]:Invalid argument [Wed Sep 8 16:03:51 2010] - Error binding stream socket to IP 2001.0.0.0 port 7100 - irc.example.com[]:Can't assign requested address While double-checking the ./configure progress I realize that eventhough IPv6 was enabled by default, --enable-inet6 was not added to the configure parameters (!). I am now adding it to the extra parameters in ./Config and I'm recompiling to see if this fixes the issue. Yup, that fixed the issue. ziplinks are not affected by this bug. I haven't tested remote includes. I'm opening a new bug report. Thanks for your attention.
(0016343) chotaire    2010-09-08 16:27	PS. It is also noteworthy to mention that the issue with autoconnect has been resolved. This ticket may be closed.
(0016347) syzop    2010-09-08 17:18	good :)

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3957	[unreal] ircd	minor	sometimes	2010-09-07 19:05	2010-09-08 17:08
Reporter:	chotaire	Platform:	x86
Assigned To:		OS:	Linux
Priority:	normal	OS Version:	2.6.34
Status:	new	Product Version:	3.2.8
Product Build:	3.2.8.1	Resolution:	open
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	Remote server disconnects do not get broadcasted via notice
Description:	Remote connects get noticed perfectly fine. However, remote disconnects do no longer get noticed (it worked in Unreal 3.1.*) unless the oper is on the server that the target server disconnected from.
Steps To Reproduce:	Connect to server A, oper up as network admin. Receive a snomask of +kcfFjveGnNqSso (all flags). Connect server C to server B on your network. Now oper up on server C and issue /die <password>. Oper on Server A will not receive any disconnect notice and will only realize if checking /links or /map. The same applies if just rebooting the machine for server C. The only occasion it is noticed when someone remotely SQUITs.
Additional Information:
Attached Files:

Notes
(0016334) chotaire    2010-09-07 19:06	Connect to server A, oper up as network admin. Receive a snomask of +kcfFjveGnNqSso (all flags). Connect server C to server B on your network. Now oper up on server C and issue /die <password>. Oper on Server A will not receive any disconnect notice and will only realize if checking /links or /map. The same applies if just rebooting the machine for server C. The only occasion it is noticed when someone remotely SQUITs.
(0016335) chotaire    2010-09-07 20:09	From what I see in source, this problem exists if the servers link via SSL links. Oper on Server B will receive a disconnect notice if SNO_JUNK is set, oper on server A will definitely not. Code can be found in ssl.c starting at line 684. While exiting clients properly get forwarded to people with snomask +F, exiting servers do not. Wanna fix?
(0016336) chotaire    2010-09-07 21:06	I just tested this thoroughly, it works fine with unencrypted links. It does not work with SSL links at any time. Happy fixing ;)
(0016337) chotaire    2010-09-07 21:28	Missing global notice: *** Global -- from x.y.z: Server u.v.w closed the connection.
(0016338) syzop    2010-09-08 12:39	There was -something- fixed related to this, I thought post-3.2.8.1. If the issue still exists in CVS, then it should be fixed before 3.2.9 release.
(0016344) chotaire    2010-09-08 16:45	I just verified and tested that the issue still exists in latest CVS.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3956	[unreal] ircd	major	always	2010-09-07 17:17	2010-09-08 13:07
Reporter:	chotaire	Platform:	x86
Assigned To:	syzop	OS:	QNX
Priority:	normal	OS Version:	6.5.0
Status:	resolved	Product Version:	3.2.8
Product Build:	3.2.8.1	Resolution:	fixed
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	Timing issue on QNX 6.5.0 in ircd.c
Description:	When starting unrealircd on QNX 6.5.0, everything seems to work just fine until taking a peak into ircd.log: [Thu Sep 2 02:19:41 2010] - TIME SYNCH: timeserver=1283818771, our=1283386781, offset = 431990 [old offset: 37] [Tue Sep 7 02:19:31 2010] - WARNING: Time running backwards! Clock set back ~-1283818771 seconds (0 -> 1283818771) [Tue Sep 7 02:19:31 2010] - [TimeShift] Resetting a few timers to prevent IRCd freeze! [Tue Sep 7 02:19:31 2010] - [TimeShift] The (IRCd) clock was set backwards. Waiting for time to be OK again. This will be in -1283818771 seconds [Tue Sep 7 02:19:34 2010] - WARNING: Time running backwards! Clock set back ~-3 seconds (1283818771 -> 1283818774) [Tue Sep 7 02:19:34 2010] - [TimeShift] Resetting a few timers to prevent IRCd freeze! [Tue Sep 7 02:19:37 2010] - WARNING: Time running backwards! Clock set back ~-3 seconds (1283818774 -> 1283818777) [Tue Sep 7 02:19:37 2010] - [TimeShift] Resetting a few timers to prevent IRCd freeze! [Tue Sep 7 02:19:40 2010] - WARNING: Time running backwards! Clock set back ~-3 seconds (1283818777 -> 1283818780) [Tue Sep 7 02:19:40 2010] - [TimeShift] Resetting a few timers to prevent IRCd freeze! [Tue Sep 7 02:19:43 2010] - WARNING: Time running backwards! Clock set back ~-3 seconds (1283818780 -> 1283818783) [Tue Sep 7 02:19:43 2010] - [TimeShift] Resetting a few timers to prevent IRCd freeze! [Tue Sep 7 02:19:46 2010] - WARNING: Time running backwards! Clock set back ~-3 seconds (1283818783 -> 1283818786) [Tue Sep 7 02:19:46 2010] - [TimeShift] Resetting a few timers to prevent IRCd freeze! [Tue Sep 7 02:19:49 2010] - WARNING: Time running backwards! Clock set back ~-3 seconds (1283818786 -> 1283818789) [Tue Sep 7 02:19:49 2010] - [TimeShift] Resetting a few timers to prevent IRCd freeze! [Tue Sep 7 02:19:52 2010] - WARNING: Time running backwards! Clock set back ~-3 seconds (1283818789 -> 1283818792) [Tue Sep 7 02:19:52 2010] - [TimeShift] Resetting a few timers to prevent IRCd freeze! [Tue Sep 7 02:19:55 2010] - WARNING: Time running backwards! Clock set back ~-3 seconds (1283818792 -> 1283818795) [Tue Sep 7 02:19:55 2010] - [TimeShift] Resetting a few timers to prevent IRCd freeze! [Tue Sep 7 02:19:58 2010] - WARNING: Time running backwards! Clock set back ~-3 seconds (1283818795 -> 1283818798) [Tue Sep 7 02:19:58 2010] - [TimeShift] Resetting a few timers to prevent IRCd freeze! [Tue Sep 7 02:20:01 2010] - WARNING: Time running backwards! Clock set back ~-3 seconds (1283818798 -> 1283818801) [Tue Sep 7 02:20:01 2010] - [TimeShift] Resetting a few timers to prevent IRCd freeze! [Tue Sep 7 02:20:04 2010] - WARNING: Time running backwards! Clock set back ~-3 seconds (1283818801 -> 1283818804) [Tue Sep 7 02:20:04 2010] - [TimeShift] Resetting a few timers to prevent IRCd freeze! [Tue Sep 7 02:20:07 2010] - WARNING: Time running backwards! Clock set back ~-3 seconds (1283818804 -> 1283818807) [Tue Sep 7 02:20:07 2010] - [TimeShift] Resetting a few timers to prevent IRCd freeze! System clock has been verified to run quite ok. It does lag behind a second every few minutes when running as virtual machine but I fixed this using regular ntpdate updates from local timeserver so the system clock is at no time ever lagging behind more than one second. kern.hz setting or similar seems to be read-only on QNX. This problem with ircd.c seems to prevent autoconnect for links (it just doesn't happen). If however manually linking the server, there is never any message about "PLEASE SYNC YOUR CLOCKS!" and similar. When linked, I see no problems on IRC network other than flooding local opers with notices (see ircd.log above) every 3 seconds.
Steps To Reproduce:	Compile unrealircd 3.2.8.1 on QNX 6.5.0 and ./unreal start ; tail -f ircd.log.
Additional Information:
Attached Files:

Notes
(0016330) ohnobinki    2010-09-07 17:28	Is this a dupe of 0003853?
(0016332) chotaire    2010-09-07 18:10	For the autoconnect issue only.
(0016340) syzop    2010-09-08 13:07    (edited on: 2010-09-08 13:08)	[Thu Sep 2 02:19:41 2010] - TIME SYNCH: timeserver=1283818771, our=1283386781, offset = 431990 [old offset: 37] that's quite a lot :) [Tue Sep 7 02:19:31 2010] - WARNING: Time running backwards! Clock set back ~-1283818771 seconds (0 -> 1283818771) this is a bug, timeofday is zero the first time... what I don't understand though is how it could have triggered...                 if (timeofday - oldtimeofday < NEGATIVE_SHIFT_WARN) { if (<something> - 0 < -somethingelse) that would be very odd :P unless, TS / time_t on QNX is unsigned ? that might explain the rest of the messages too.. Ah yes... "The consensus is for time_t to be signed, and this is the usual practice. The software development platform for version 6 of the QNX operating system has an unsigned 32-bit time_t, though older releases used a signed type." Fun. Ok, I've fixed this in CVS [.877]: - Fixed another compile problem on QNX, reported by chotaire (0003955 too). - Fixed incorrect messages regarding clock going backwards on QNX 6 and   later, reported by chotaire (0003956). Thanks for the report. If that somehow didn't fix it, let us know.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2973	[unreal] ircd	minor	always	2006-06-15 08:09	2010-09-06 15:07
Reporter:	vonitsanet	Platform:
Assigned To:	ohnobinki	OS:	FreeBSD
Priority:	normal	OS Version:	6
Status:	assigned	Product Version:	3.2.5
Product Build:	1.1.1.1.2.1.2.1.2.2234.2.537	Resolution:	open
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	override bug
Description:	As netadmin with override i cant DEOP a user if i have (+h or) +o or +a -> [15:56:48] * Netadmin sets mode: +oao Netadmin user user /mode #test -o user and then the error: o user is a channel admin if i dont have any modes (h,o,a) i can override just nice and with +o i can -a. The problem is on DEOP. Another (if netadmin with override is halfopped and not opped on the channel): o user is a channel admin h user is a channel admin a user is a channel admin
Steps To Reproduce:
Additional Information:	You can give channel modes to a user with override. The problem is when you try to remove them.
Attached Files:

Notes
(0011957) JasonTik    2006-06-15 16:10	I have to say, I've never had this problem. Sure your netadmin, not servicesadmin or etc?
(0011962) vonitsanet    2006-06-15 20:31	ME is using modes +iowghraAsRTxNWqztGp
(0011986) Zell    2006-06-19 01:53	I'll be d**mned. It happens on 3.2.5, too. I was +h at channel, and every operator flag known to God and man set. I set my net comanager +q on the channel and me +h, and tested this out. Results: q tigger-away is channel owner a tigger-away is channel owner o tigger-away is channel owner (when user was +q at channel) a tigger-away is channel admin o tigger-away is channel admin (when user was +a at channel)
(0011992) vonitsanet    2006-06-19 22:24	Exactly
(0013425) WolfSage    2007-04-15 20:44	Just tested, and verified. I think this should be fixed in 3.3.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2535	[unreal] documentation	minor	always	2005-05-25 14:26	2010-09-06 15:05
Reporter:	Digerati	Platform:
Assigned To:	ohnobinki	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	Ban/TKL Exception Blocks Clarification
Description:	Section 4.19: "The except ban block allows you to specify a user@host that will override a ban placed on a broader host..." Section 4.20: "The except tkl block allows you to specify a user@host that will override a tkl ban placed on a broader host." I suggest that section 4.19 be updated to be more clear on the purpose of this block. From what I understand, except ban overrides ban blocks in unrealircd.conf, and except tkl overrides tkl bans. It should be made clear that the except ban overrides blocks like the ban version, real name, etc. blocks.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0009986) Digerati    2005-05-25 14:36	According to aquanight in #unreal-support: (14:07:24) (@aquanight) Digerati: except ban also affects bans via /kline (14:07:37) (@aquanight) and /zline If this is true (which I assume it is), this definately needs to be explained more clearly in the docs, and the specific differences between except ban and except tkl need to be distinguished.
(0009993) aquanight    2005-05-25 23:29	I think it can be basically explained like this: except tkl is exception from any (or all) of: gline, qline (ban nick {} or tkl, interestingly enough (no unreal does not have a builtin way to add tkl local qlines)), gqline (or sqline if you prefer), shun, gzline. except ban is exception from all of: kline, zline (ban user/ip {} or tkl). There is no exempt from spamfilter (short of oper{}, although when the kline/zline/gline/gzline spamfilter actions are used the corresponding except blocks apply). Yes, I think the docs should probably mention this all :P .
(0010047) White_Magic    2005-06-06 08:16	so basically, add a ban exception block rather than a tkl with all the types :P
(0013877) stskeeps    2007-04-27 06:42	Bump. Still an issue?
(0016176) syzop    2010-07-14 17:38	I don't know if this has been documented already, but we fixed some stuff related to this in the source, see changelog. The docs must reflect the current behavior (both the stuff below, and the stuff in this bugreport above). - except ban { } is now also effective against Z:lines. It already protected   when the user was connected, but not once he/she tried to reconnect, this   is now fixed. Reported several times, last by Stealth in 0003377.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3776	[unreal] ircd	feature	N/A	2009-01-04 11:48	2010-09-06 11:07
Reporter:	syzop	Platform:
Assigned To:		OS:	All
Priority:	normal	OS Version:	All
Status:	new	Product Version:	3.2.9
Product Build:		Resolution:	open
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	Unreal3.2.9 TODO
Description:	Parent bug of TODO's for 3.2.9.
Steps To Reproduce:
Additional Information:	Usual disclaimer: * Some things here might not be done, many other things not mentioned here will be done. * Please do not post any bugnotes here. Post bugnotes in the original bugreports instead. Understand, though, that mass-posting to every and each issue "this should be in next version" will not be appreciated either. * There's no clear ETA regarding this release, and if any estimate is given at a later point, then understand that these are date/time ESTIMATES, and are rarely 100% correct.
Attached Files:

Notes
(0016159) syzop    2010-07-14 16:51	Ok, I'm going to compile a list of things that should/will be done in 3.2.9. These will be the only issues that will be looked at. (note to my fellow developer ohnobinki: that means only these ones may be committed and the ones we already talked about). While I may say here and there in a bug that it will be rescheduled for 3.2.10, I won't do that for all 200+ issues.. so if it's not on the list, you may assume it is not scheduled to be in 3.2.9. I want to release a 3.2.9 someday, and it does not help when constantly new issues get added to the list and patches being committed which are dubious to do right before release. I'd like to release 3.2.9 this Summer (northern hemisphere ;p), but don't ask for an exact date or month :). Please give me a few days or so to compile the full list.
(0016181) syzop    2010-07-14 17:58	Ok, I'm like 75% through the bugitems now. Release Critical: 0003916 0003720 0003893 #2837 (last one is private) I forgot to mention, any doc bugs (be it in the HTML, the tech docs, or helpop etc), you may commit freely :P. There's a closing window for them, to give translators some time to get everything synchronized, but that's to be decided at a later point, and not within a month I think... I'll post a note here when it happens.
(0016191) syzop    2010-07-14 21:34	Ok, I've gone through all bugs now. Quite inspiring ideas you see again when you do that, but most of them are for next release or after that... ;p
(0016329) syzop    2010-09-06 11:07    (edited on: 2010-09-06 11:09)	Are there any bugids I can offer to you binki? 0003893 0003358 0002535 0002973 come to my mind I'll do 0003720 and 0001522 myself (in that order), and then move on to any remaining issues. EDIT: I don't know how quickly I'll finish them, it'll be 'next weekend' again ;) I wouldn't mind if you did 0003848 and/or 0003943 either, but since it's Windows-related... :p It would be nice if we could finish our work this month (September), and then go into testing mode...

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3953	[unreal] ircd	minor	N/A	2010-08-31 05:12	2010-09-03 02:59
Reporter:	Nath	Platform:
Assigned To:		OS:	Linux/Windows
Priority:	normal	OS Version:	Ubuntu (Linux)
Status:	confirmed	Product Version:	3.2.8
Product Build:		Resolution:	open
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	Oper Idle times.
Description:	After reading through the m_whois.c file, I cam across a comment which didn't really apply to what the code was actually doing. The comment in question: /* * Fix /whois to not show idle times of * global opers to anyone except another * global oper or services. * -CodeM/Barubary */ The code didn't appear to actually do that at all. So I decided to patch a usermode that opers can set, to hide their idle time if they so wish. I have chose the usermode +I. For 2 reasons: "I" can easily relate it "IDLE" and so seems practical to use. "I" also can redeem itself as a sensible umode, and could potentially cause hassle for any more +I invisible hacks out there. I have uploaded my patch, any constructive criticism is welcome. :)
Steps To Reproduce:
Additional Information:
Attached Files:	hidle.patch (2 KB) 2010-08-31 05:12 unreal-3953-hidle-r1.patch (3 KB) 2010-09-02 22:10

Notes
(0016322) ohnobinki    2010-08-31 22:14	In the diff in umodes.c, I suggest to try to fit in to the surrounding convention of 0L instead of 0l. I don't understand why you're adding minus signs in the middle of m_whois.c and gcc doesn't either: gcc -I../include -pipe -g -O2 -funsigned-char -fno-strict-aliasing -Wno-pointer-sign -export-dynamic -fPIC -DPIC -shared -DDYNAMIC_LINKING \                 -o m_whois.so m_whois.c m_whois.c: In function 'm_whois': m_whois.c:332: error: wrong type argument to unary minus make[2]: *** [m_whois.so] Error 1 In the comment about ``Umode I'', howabout ``Umode +I''? The + is a visual aid to me, not sure about others ;-). And prepend ``Nath'' with a `-' :-p And I personally prefer simpler logic: !((acptr->umodes & UMODE_HIDLE) && !IsAnOper(sptr)) could become the following perhaps? (IsAnOper(sptr) || !(acptr->umodes & UMODE_HIDLE))
(0016323) Stealth    2010-09-02 21:55	This is definitely a good idea, and I do agree with needing a little bit of cleanup to ensure that it is both functional and bettering the source.
(0016324) ohnobinki    2010-09-02 22:23	unreal-3953-hidle-r1.patch: Fixes the things I addressed, compiles, and appears to work. On a separate note, the m_whois.c lines that this patch modifies happens to be the line that causes user idle times to only show up if the WHOISee and the WHOISer are both on the same server. I.e., this ``MyConnect(acptr)'' check. Is this intended or should I open another bug to enable idle times to be checked from different servers?
(0016325) Stealth    2010-09-03 02:59	Not showing remote idle times is intentional behavior (as most IRCds do this). To see remote idle times, you need to send "WHOIS <nick> <nick>". This might be addressed somewhere else in the source, as a server-server WHOIS is different than client-server.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3943	[unreal] ircd	major	unable to reproduce	2010-08-13 11:07	2010-08-27 18:37
Reporter:	syzop	Platform:	Any
Assigned To:		OS:	Windows
Priority:	normal	OS Version:	???
Status:	feedback	Product Version:	3.2.8
Product Build:		Resolution:	open
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	loadmodule permission denied errors on windows
Description:	It seems we frequently get users with 'Permission denied' problems in the support channel, and sometimes on the forums. However, there has never been a bugreport about it. I wonder what's causing these errors, and if we can do something about it to prevent them... either in the installer or in Unreal. It seems to happen more often than before, when I thought it was just someone incorrectly CACLS'ing or whatever their c:\program files, it seems to be a more general issue now... I've never experienced the issue myself (XP), so any advice on how to reproduce it would be nice. Stealth, or anyone else? :P
Steps To Reproduce:
Additional Information:	It's not my idea to add issues this late for release, but if this could be fixed for 3.2.9 it would be nice, it seems like a real issue.. but I don't know how big it is or how easy or hard to fix...
Attached Files:

Notes
(0016310) Bock    2010-08-24 22:48	Unreal installer want admin rights for setup. http://a.imageshack.us/img26/499/unrealwarn01.png [^] Cannot run makecert.bat after install under user http://a.imageshack.us/img90/3699/unrealwarn04.png [^] Only if I give admin rights for me through Properties - Security to whole folder Unreal 3.2 it give to me write/read files and run unreal just starting wircd.exe If I check "install as service", service is installed, but makecert.bat have the same problem. I need to open "cmd" as admin and start makecert.bat in Unreal3.2 dir. I don't see loadmodule error in my Win 7 (x64).
(0016321) KnopeX    2010-08-27 18:37	Since i have UnrealIRCd on Win7 i didn't notice a error when i loaded a 3rd party module or something else...

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3922	[unreal] ircd	feature	N/A	2010-07-12 10:51	2010-08-27 06:22
Reporter:	warg	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	badwords exemption
Description:	The ability to exempt groups of people from the badwords filter would be neat.
Steps To Reproduce:
Additional Information:	# example: set {     # exempts +%@&~ from badwords     badwords-exempt "+";     # exempts %@&~ from badwords     badwords-exempt "%";     # exempts @&~ from badwords     badwords-exempt "@";     # exempts &~ from badwords     badwords-exempt "&";     # exempts ~ from badwords     badwords-exempt "~"; };
Attached Files:

Notes
(0016314) ohnobinki    2010-08-26 04:36	What's the point of having badwords enabled at all if channel ops are going to break them?
(0016320) warg    2010-08-27 06:22	last i checked it wasn't up to us to decide what the point of anything is :P but i agree, but i still think the feature would be useful in special cases, and if for specific channels, not server-wide.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3157	[unreal] ircd	minor	always	2006-12-20 21:08	2010-08-26 05:23
Reporter:	vonitsanet	Platform:
Assigned To:		OS:	-
Priority:	normal	OS Version:	-
Status:	acknowledged	Product Version:	3.2.6
Product Build:	RC3	Resolution:	open
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	More descriptive SSL error messages (underlying syscall error, etc)
Description:	When a connection between 2 connected servers (both rc3) with ssl + zib was lost i was seen this AND ONLY this without the junk snomask: -FBSD6.unrealircd.testnet- Lost connection to WinXPPro.nonSSL.unrealircd.testnet[75.75.21.39]: SSL_read(): Underlying syscall error vonitsanet +iowghaAsxNzG Server notice mask (+kcfFvGqso)
Steps To Reproduce:
Additional Information:
Attached Files:	unreal-3157-ssl-errno-condense.patch (6 KB) 2010-08-26 05:03 unreal-3157-ssl-errno-condense-r1.patch (7 KB) 2010-08-26 05:15

Notes
(0012865) Bricker    2006-12-20 21:11	I got this error on my side of the netsplit >[Dec 20 2006 21:29:10] Lost connection to FBSD6.unrealircd.testnet[72.20.15.245]: SSL_read(): Underlying socket operation returned zero
(0012868) Bock    2006-12-21 01:22	and? /me don't see bug in this case - error of OpenSSL is difficult to see ;] I see:  -win2003.unrealircd.testnet- *** LocOps -- Received SQUIT FBSD6.unrealircd.testnet from Bock|work[193.232.250.240] (@test!) in other side:  -FBSD6.unrealircd.testnet- Lost connection to win2003.unrealircd.testnet[195.222.64.143]: SSL_read(): Underlying socket operation returned zero tcp-kill: -win2003.unrealircd.testnet- Lost connection to FBSD6.unrealircd.testnet[72.20.15.245]: SSL_read(): Underlying syscall error  -FBSD6.unrealircd.testnet- Lost connection to win2003.unrealircd.testnet[195.222.64.143]: SSL_read(): Underlying syscall error
(0012870) syzop    2006-12-21 07:40	So ehm.. it gives an error? good then... I don't understand.. what's the bug? :P
(0012872) Bock    2006-12-21 07:59	/me don't see bug too :]
(0012873) syzop    2006-12-21 08:54	or do you mean a better error *description* perhaps? yeah there's still room for improvement there. basically what I fixed was that at least an error message is *shown* ;). Previously you could have seen no error at all (except with junk snomask), which was.. not good :P.
(0012874) Bricker    2006-12-21 10:25	yeah, the description to me looks fucked up
(0012880) syzop    2006-12-21 17:54	I've changed the title to "More descriptive SSL error messages (underlying syscall error, etc)" and will add it as a child to 3.2.7. If this was an incorrect assumption (see also previous comments), then let me know. Thanks.
(0012882) vonitsanet    2006-12-21 19:44	"More descriptive SSL error messages" Yep ;)
(0016317) ohnobinki    2010-08-26 05:08	unreal-3157-ssl-errno-condense.patch: This was originally written to get rid of code duplication between fatal_ssl_error() and ssl_error_str(). As a side-affect, calls to fatal_ssl_error() now get errno passed along. Unfortunately, it seems that even this isn't providing too much useful information: :test.ohnopub.net NOTICE a :*** Notice -- Client connecting on port 6338: b (ohnobinki@localhost) [clients] [secure AES256-SHA] :test.ohnopub.net NOTICE a :Exiting ssl client b[ohnobinki@127.0.0.1.36116]: SSL_read(): Underlying syscall error [Success] :test.ohnopub.net NOTICE a :*** Notice -- Client exiting: b (ohnobinki@localhost) [Input/output error] Reminds me of the ``Success'' socket error that clients quit with when not using SSL. I'm not too creative, maybe I could've simulated some more catastrophic disconnection which would display something other than ``Success''... or maybe errno is being trampled on before I store a copy of it. Oh, likely that Debug() function calls vsprintf...
(0016318) ohnobinki    2010-08-26 05:23	unreal-3157-ssl-errno-condense-r1.patch: This version supposedly saves errno before the Debug() call for SSL_read() and SSL_write() but I still don't get anything other than ``Success''. I guess this would potentially be more reliable... if it helps at all. I'm not sure how to generate an error other than ``success''.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3920	[unreal] documentation	minor	always	2010-07-12 09:16	2010-08-26 04:42
Reporter:	warg	Platform:
Assigned To:	Stealth	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	http://forums.unrealircd.com/viewtopic.php?f=3&t=353 [^]
Description:	http://forums.unrealircd.com/viewtopic.php?f=3&t=353 [^] This should be updated, appended, or in some way refer to curlinstall
Steps To Reproduce:
Additional Information:	Cookies to ErikMouse
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3921	[unreal] ircd	feature	N/A	2010-07-12 10:46	2010-08-26 04:37
Reporter:	warg	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	auto-join delay
Description:	An option to set a delay would be great for auto-join and oper-auto-join. Perhaps even an override, to allow an auto-join to a channel whose modes normally wouldn't permit it.
Steps To Reproduce:
Additional Information:	# example: set {     auto-join "#chan1,#chan2";     auto-join-delay 1s;     auto-join-override yes; }; # or set {     auto-join {         channels "#chan1,#chan2";         delay 1s;         override yes;     }; };
Attached Files:

Notes
(0016315) ohnobinki    2010-08-26 04:37	Why is a delay needed?

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2406	[unreal] ircd	feature	N/A	2005-03-07 13:54	2010-08-25 15:32
Reporter:	Ron2K	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	acknowledged	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	[Feature Request] /ELINE - exceptions for /GLINE
Description:	This is a request for an /ELINE command; it would place /GLINE exceptions (much like channel mode +e can override channel mode +b). (Feel free to change the name /ELINE if you don't like it.) Having such a command would allow GLINE exceptions to be set on the fly (currently, one has to add a ban exceptions block and rehash, which could be impractible in some situations). The command should take the same parameters and have the same syntax as the /GLINE command. ELINEs could also be set to expire after a set time period, much like GLINEs. Additionally, services packages should be able to take advantage of this feature (IRCServices would be able to do so if the EnableExclude option was enabled). Currently, IRCServices (and probably other services packages as well) do not set GLINEs if autokill exceptions are enabled, due to the lack of this feature, and instead fall back to issuing a /KILL for users that match autokill masks. This causes more traffic on the network (as well as the possibility that an autokilled user will get a message in before the /KILL is sent if the network is laggy enough). I thought of this after reading a forum post by Zell; and therefore think that he should be co-credited with this should it be implemented. (Reference: http://www.phpmemx.net/~unrealir/forums/viewtopic.php?t=1592) [^] Hopefully I've submitted all required information for this request. If there's anything that you think that I've left out, please let me know.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0009481) Zell    2005-03-07 15:45	Righty-o. Coders of Unreal: should this feature be implemented, a module for Anope will be created forthwith. The closer the code is to the m_tkl code, the easier it will be for Services packages to implement the feature in services. I (and anyone else who wants to) will make a module for anope upon completion of this feature. Other services coders, now is your time to be ready for this feature.
(0009540) vonitsanet    2005-03-09 03:25	I will be very happy if this was added sometime:P We need many times akill exceptions but we cant enable it coz ircservices does not add glines..
(0009542) medice    2005-03-09 03:50	why do you use akills, since unreal supports gline which is imo easier to handle
(0009544) vonitsanet    2005-03-09 06:41	medice this is not the point of this thing. I said IF i use the akill exception feature for ircservices (and other services packages) and add an akill... services does not add glines because unrealircd does is not supporting glines exceptions (ELINES). So servces can't manage exceptions with any other way.. They just issue /kill for the akills and allows the exceptions to pass.
(0009701) Knippy    2005-04-03 21:29	I like this idea
(0010985) Ron2K    2006-01-20 12:59	Syzop/codemaster: any word on this one? (Yeah, I know, I should have followed up on this a LOT earlier, but my computer has been up the creek without a paddle for the last few months. BTW: I'm not expecting this to go into 3.2.x)
(0010986) Zell    2006-01-20 15:29	Time for my two cents again =) I still think the ELINE is a good command addition. Some servers/ircds already support exemptions... anyone remember AKILLEX/RAKILLEX ? Bingo =) $0.02 deposited to Bugs forum. :-P
(0010989) JasonTik    2006-01-20 19:47    (edited on: 2006-01-21 14:52)	I have an issue with this command. What does it exempt you from? gline? ok. how about gzline, shun, kline, zline, and other things like that. will it override config bans? Whatever you say it will or wont do, I'm a user who wants it the other way. (So really, this is impractical unless we add another field, which breaks TKL compatibility.)
(0011002) Ron2K    2006-01-22 02:13    (edited on: 2006-01-22 02:25)	Which is why, in my opinion, it should only be added (if at all) when 3.3 gets developed. Now let's see... it would only affect glines, seeing as that's the only thing that you can have exceptions for in the conf file (EDIT: OK, just opened up the conf file and I'm horribly wrong, but seeing as services programs will probably only support gline exceptions (eg ircservices), let's keep it as gline exceptions only. Feel free to disagree with me here if you want.) I'm not sure whether or not this should override conf bans and I'm prepared to listen to both sides of that argument.
(0011020) Zell    2006-01-22 16:37	m, maybe. As it stands, lets take an example of the opposite. Suppose you have a config exemption for kline on NiceGuy@*.rr.com Suppose you /kline *@*.rr.com 0 :Bug off Mr. NiceGuy does not get klined (the new command issued did not override the config) So in that sense, the ELINE command shouldnt override config bans... But on the other side, if you have a nasty config ban (that for some reason is wide but necessary (*.aol.com, anyone?)), then you can on-the-fly exempt specific users.. (StarChat does this with their AOL Registration script on their website)
(0011065) Ron2K    2006-01-26 12:12	Zell, you make a valid point. What I'll do is take a look at InspIRCd (if I can get it to compile on Cygwin) and see how they implement it. They have /ELINE, if I remember correctly.
(0011094) vonitsanet    2006-01-28 16:31	Is this on TODO for 3.2.4 or is something for the 3.3.x ?
(0011096) Stealth    2006-01-28 20:55	If this already is not in 3.2.4, it won't be in it... Maybe next version
(0011288) Ron2K    2006-02-23 11:25	OK, I haven't been able to get InspIRCd working (I'm probably doing something stupid) - but I've been thinking about the whole overriding conf bans idea, and I think that Zell is right there - this shouldn't override them.
(0011289) syzop    2006-02-23 15:00	Strange I never commented on this one, guess I only talked with codemastr about it (long ago). I find this a nice feature, and I don't exclude the possibility that it will end up in 3.2* ;).
(0011295) aquanight    2006-02-25 00:08	If it's going to exempt from gline only then whether or not it overrides conf bans is moot: G:Lines can't be set in the conf.
(0016311) KnopeX    2010-08-25 10:12	You mean ELINE like except ban { } and/or except tkl { } ? Nice idea BTW :)
(0016313) Zell    2010-08-25 15:32	KnopeX: Yes, exactly. Coders: Any word on this actually getting implemented?

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3950	[unreal] ircd	minor	have not tried	2010-08-25 06:43	2010-08-25 06:50
Reporter:	ohnobinki	Platform:
Assigned To:	ohnobinki	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:	3.2.8
Product Build:	CVS	Resolution:	open
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	oper-up message uses vhost instead of realhost
Description:	because people are too lazy to file their own bug reports: 2010/08/25 22:35 -!- Josh [Josh@Clk-77AA73F3.ri.ri.cox.net] has joined #unreal-support 22:35 -!- mode/#unreal-support [+v Josh] by UnrealHelper 22:36 <+Josh> Hey, is there any way when a staff member opers up I can get the server notice to show the real host instead of the masked one? 22:40 <~Stealth> ermmm... the oper notifications always show the real host 22:41 <+Josh> It shows the failed oper attempt's real host, but not a successful oper. 22:44 <@Jobe> thats a bug iirc 22:44 -!- infidel [~ecc@Clk-E2BE66C1.membersrealm.com] has quit [Ping timeout] 22:45 <@Jobe> hmmm 22:45 <@Jobe> the failed attempts use sptr->sockhost but the success notices use GetHost(sptr) 22:45 <@Jobe> :/ 22:47 <+Josh> So, I'll take it as there's nothing I can do about it atm? 22:49 <@Jobe> report it on the bug tracker 22:49 <@Jobe> its still present in the current CVS revision as far as I can see 22:50 <+Josh> Will-co 22:50 <~Stealth> maybe binki will fix 22:50 <@Jobe> Stealth, dont we have to rape him to get him to work though? 22:50 <@Jobe> well that or bribery For logging purposes/automated parsing of the snomasked notice, it would seem to make sense for the realhost to be provided. I don't think there is any reason to preserve display of the vhost in the notice.
Steps To Reproduce:	Example logs: notices: 00:36 [ohnopub] !ohnopublishing.net a (ohnobinki@undisclosed-981307ED) [binki] is now a network administrator (N) 00:36 [ohnopub] !ohnopublishing.net a (ohnobinki@test.net) [binki] is now a network administrator (N) 00:39 [ohnopub] !ohnopublishing.net Failed OPER attempt by a (ohnobinki@localhost) using UID binki [FAILEDAUTH] commands: USER a b c d e f NICK a OPER binki <password> SETHOST test.net MODE a -o OPER binki <password> MODE a -o OPER binki wrongpassword
Additional Information:	Expected behavior: the successful oper-up message should give the same host as the failure message.
Attached Files:	unreal-3950-oper-up-no-vhost.patch (2 KB) 2010-08-25 06:50

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3949	[unreal] ircd	text	have not tried	2010-08-25 06:25	2010-08-25 06:26
Reporter:	ohnobinki	Platform:
Assigned To:	ohnobinki	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:	3.2.8
Product Build:	CVS	Resolution:	open
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	./ircd --help should output usage information.
Description:	Yes, I know that --help isn't actually a switch for unrealircd. But passing an invalid switch does cause the usage information to be printed out. I am filing this bug because I had to make some non-text changes to better improve the usage output and thus it should be reviewed.
Steps To Reproduce:
Additional Information:
Attached Files:	unreal-3949-more-usage.patch (3 KB) 2010-08-25 06:25

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3948	[unreal] ircd	minor	N/A	2010-08-24 19:09	2010-08-24 19:09
Reporter:	Eman	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	Drop webtv support
Description:	webtv aka msntv is effectively dead at this point. i suggest removing support for it from unreal. from #unreal3-devel [2010/08/24 - 1:04:08PM] <Erik> binki: i cant help but think that maybe its time to drop webtv support [2010/08/24 - 1:04:43PM] <@binki> erik: help me by filing a bug asking for that :-D [2010/08/24 - 1:04:52PM] <@binki> i.e., that's what I'd like to do too
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3947	[unreal] ircd	minor	always	2010-08-23 20:58	2010-08-24 18:49
Reporter:	KnopeX	Platform:	All platforms
Assigned To:	ohnobinki	OS:	Windows and all other
Priority:	normal	OS Version:
Status:	resolved	Product Version:	3.2.8
Product Build:	3.2.8.1 and older	Resolution:	fixed
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	/msg IRC whois <nick>: <nick> is a Secure Connection
Description:	Hello, I found a bug in /msg IRC whois <nick> function. Looks like this: <IRC> Shichirobei is a Secure Connection <- 'using' is missing. Thanks. Regards, KnopeX
Steps To Reproduce:	Type /msg IRC whois <nick> But only users using SSL connections.
Additional Information:
Attached Files:

Notes
(0016309) ohnobinki    2010-08-24 18:49	- Fix /msg IRC WHOIS response for persons with secure connections. (0003947) In CVS and will be in 3.2.9. Thanks for the report. However, note that the /msg IRC WHOIS ``feature'' should not be relied upon. (hopefully it will disappear someday ;-)).

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3945	[unreal] installing	minor	have not tried	2010-08-16 03:01	2010-08-23 22:54
Reporter:	ohnobinki	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:	3.2.8
Product Build:	CVS	Resolution:	open
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	./Config should support --with-system-cares and --with-system-tre
Description:	Currently, ./configure will by default compile a bundled version of TRE and c-ares. There is the possibility that a user will not want to do that and knows that his copy of libtre or c-ares is reliable (e.x., this person uses a package manager for everything but unrealircd itself because he wants to compile special unreal modules). I do not think that a user could reasonably be expected to find out about the --with-system-tre and --with-system-cares ./configure options. Perhaps two new questions can be added to ./Config -advanced? I would like to get clearance on this before writing the patch ;-).
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0016294) Bock    2010-08-20 13:33	I think it must be added to ./Config -advanced We use debian and using system libs will be perfect.
(0016295) ohnobinki    2010-08-20 14:19	> We use debian and using system libs will be perfect Then you should probably start petitioning for debian to version bump their libc-ares2 package to >= 1.6.0 ( https://bugs.launchpad.net/debian/+source/c-ares/+bug/561942 [^] ) and ascertain that https://bugs.launchpad.net/ubuntu/+source/tre/+bug/561933 [^] isn't also a debian bug ;-). UnrealIRCd should work fine with c-ares-1.5, but its buildsystem and #error directives force you to use 1.6.0 or greater. UnrealIRCd depends on pkg-config files when compiling against a system-installed libtre or c-ares. Otherwise, you'll need to specify CARES_LIBS and CARES_CFLAGS manually, which is just annoying.
(0016296) Bock    2010-08-20 14:43	you can see our "unoficcial" debs for unreal. ftp://ftp.bynets.org/debian/ [^] Libs present in depends. In /version from our servers: 15:36:29 -!- Unreal3.2.8. solo.bynets.org FhinXeOoZEmM3 [Linux solo 2.6.26-2-686 #1 SMP Wed May 12 21:56:10 UTC 2010 i686=2309] 15:36:29 !solo.bynets.org OpenSSL 0.9.8g 19 Oct 2007 15:36:29 !solo.bynets.org zlib 1.2.3.3 15:36:29 !solo.bynets.org libcurl/7.18.2 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.8 libssh2/0.18 or: 15:37:45 -!- Unreal3.2.8. irc.mgts.by FhinXeOoZEmM3 [Linux irc 2.6.26-2-vserver-amd64 #1 SMP Thu Nov 5 03:47:07 UTC 2009 x86_64=2309] 15:37:45 !irc.mgts.by OpenSSL 0.9.8c 05 Sep 2006 15:37:45 !irc.mgts.by zlib 1.2.3 15:37:45 !irc.mgts.by libcurl/7.15.5 OpenSSL/0.9.8c zlib/1.2.3 libidn/0.6.5 but: "/quote dns i" give and I think, what we use c-ares from unrealircd. Maybe check version of c-ares in distro for enable/bisable "--with-system-cares" 15:41:25 -!- ****** DNS Configuration Information ****** 15:41:25 -!- c-ares version: 1.6.0 15:41:25 -!- timeout: 3000 15:41:25 -!- tries: 2 15:41:25 -!- # of servers: 1 15:41:25 -!- server #1: 127.0.0.1 15:41:25 -!- ****** End of DNS Configuration Info ******
(0016298) ohnobinki    2010-08-20 16:06	> Maybe check version of c-ares in distro for enable/bisable "--with-system-cares" I'm having trouble understanding what you're saying ;-). --with-system-cares (0003847) and --with-system-tre (0003842) already exist in CVS. This bug is a request to give these options more public by adding direct support for them into ./Config so that users know these options are available. > you can see our "unoficcial" debs for unreal. Cool. However, I don't use Ubuntu ;-). I just want you to push your distro's packagers and it seems more your role to do that than mine. hrrm... I think I'm wrongly using the bug tracker as if it were the forums :-/.
(0016299) Bock    2010-08-20 18:26	I'll check in Monday in debian/testing.
(0016302) Bock    2010-08-23 08:23	compiled unreal with parameters: ./configure --enable-libcurl --with-showlistmodes --with-topicisnuhost --enable-nospoof --enable-ssl --with-shunnotices --enable-ziplinks --enable-prefixaq --with-listen=5 --with-dpath=/usr/local/src/Unreal3.2.9 --with-spath=/usr/local/src/Unreal3.2.9/src/ircd --with-nick-history=2000 --with-sendq=3000000 --with-bufferpool=18 --with-permissions=0660 --with-fd-setsize=1024 --enable-dynamic-linking --with-system-cares --with-system-tre installed package: libc-ares-dev, libssl-dev, zlib1g-dev, libcurl4-openssl-dev | libcurl-dev, libtre-dev ./unreal start Starting UnrealIRCd  _ _ _ ___________ _____ _ | | | | | |_ _| ___ \/ __ \ | | | | | |_ __ _ __ ___ __ _| | | | | |_/ /| / \/ __| | | | | | '_ \| '__/ _ \/ _` | | | | | / | | / _` | | |_| | | | | | | __/ (_| | |_| |_| |\ \ | \__/\ (_| |  \___/|_| |_|_| \___|\__,_|_|\___/\_| \_| \____/\__,_|                            v3.2.8.1                      using TRE 0.8.0 (BSD)                      using OpenSSL 0.9.8o 01 Jun 2010                      using zlib 1.2.3.4                      using libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.15 libssh2/1.2.6 * Loading IRCd configuration .. * Configuration loaded without any problems .. * Initializing SSL. * Dynamic configuration initialized .. booting IRCd. --------------------------------------------------------------------- Checked remote include (checking curl-config... yes configure: WARNING: cURL seems compiled without c-ares support. Your IRCd will possibly stall when REHASHing!) - worked fine and rehashing so fast. Do you needed ane config.log or something? Debian version: squeeze (testing).
(0016303) ohnobinki    2010-08-23 14:12	> Checked remote include (checking curl-config... yes > configure: WARNING: cURL seems compiled without c-ares support. Your IRCd will possibly stall when REHASHing!) - worked fine and rehashing so fast. This means that your system-installed libcurl should be rebuilt with c-ares support. See that the output of the following command on your machine looks different from mine: ohnopublishing portage # pkg-config --variable supported_features libcurl "SSL IPv6 libz AsynchDNS NTLM" You're missing ``AsynchDNS''. See ``asynchonous name resolving'' under http://curl.haxx.se/docs/features.html [^] > Do you needed ane config.log or something? I'm not sure what you're asking :-/.
(0016304) Bock    2010-08-23 15:05    (edited on: 2010-08-23 15:11)	pkg-config --variable supported_features libcurl "SSL IPv6 libz IDN NTLM" for what purposes need c-ares in curl? For downloading files? I have in conf: include "ftp://ftp.bynets.org/configs/unreal/badwords.all.conf"; [^] and in tmp/ file present: -rw------- 1 bock staff 1912 ??? 20 2006 EA2B302D.badwords.all.conf After rehashing: -rw------- 1 bock staff 1912 ??? 20 2006 38E31C42.badwords.all.conf Ah, I understand. If ftp not avaliable, ircd not freeze, just continue working. In debian I didn't find package curl with c-ares.
(0016305) ohnobinki    2010-08-23 15:13	> for what purposes need c-ares in curl? For downloading files? For remote includes support. > If ftp not avaliable, ircd not freeze, just continue working Actually, if your DNS is down or slow and your curl doesn't support c-ares, it'll freeze. > In debian I didn't find package curl with c-ares. Time for you to file some bugs against debian? :-p
(0016306) Bock    2010-08-23 15:47	16:46:44 -!- unrealircd.conf Rehashing 16:46:59 !belarusbank.local *** Notice -- Loading IRCd configuration .. 16:46:59 !belarusbank.local *** Notice -- [warning] unrealircd.conf:7: include: error downloading           'ftp://ftp.bynets.org/configs/unreal/badwords.all.conf': [^] Couldn't resolve host 'ftp.bynets.org' -- using cached version instead. 16:46:59 !belarusbank.local *** Notice -- Configuration loaded without any problems .. True.. 15 seconds.
(0016308) Bock    2010-08-23 22:54	Hm. This bug ONLY if dns working slow or not avaliable and oper do /rehash. If dns configured correctly, all other errors (file not found, host not resolved, etc) - no this delay. I think that not so many people rehashing their IRCd every 15 mins or so.. In case with --enable-libcurl give a warning, that system don't sypport asyns dns requests and maybe slow down on rehashing. On --with-system-cares just check for version (=> 1.6.0).

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3705	[unreal] ircd	minor	N/A	2008-06-18 20:59	2010-08-23 19:02
Reporter:	Stealth	Platform:	*
Assigned To:		OS:	*
Priority:	normal	OS Version:	*
Status:	new	Product Version:	3.2.7
Product Build:		Resolution:	no change required
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	Review Gentoo Patches
Description:	We should check out the Gentoo patches to see if they were real 'security issues' or just the Gentoo people doing stupid stuff with our IRCd. If the patches really do fix stuff, they should be applied.
Steps To Reproduce:
Additional Information:
System Description
Attached Files:

Notes
(0015314) cdf123    2008-06-27 16:05	Please take a look at this bug. I would be interested to know if the module copy before load is needed. http://bugs.gentoo.org/show_bug.cgi?id=223835 [^] Trusted Path Execution in the grsecurity patches breaks unrealircd by preventing any modules from loading. The /tmp/*.so module is owned by a non-root and non-tpe-trusted user and gets denied execution.
(0015317) w00t    2008-07-02 14:57	It's most assuredly not required if the install process operates 'properly', which it currently doesn't By that, I mean that using 'cp' and equivilants to move shared objects around breaks things, which this copy hack is aimed at bypassing - if instead of this, shared objects were installed into a lib/ directory (or whatever) inside Unreal's folder through `install' (1) instead of cp, the problems of overwriting shared objects while running would go away. (We had this problem with InspIRCd a few years ago - I'm surprised nobody's found the solution yet..) Though, I'm not sure what kind of a timeline you'd see on a fix, cdf123. Things have been a bit slow for a while here.
(0015336) syzop    2008-08-04 08:26	If your question is why we are copying to a tmp directory (tmp/ inside of the Unreal directory of course, not /tmp.. that would be a horrible idea) then the answer is: because otherwise a new version of a module would not load. This is because Unreal does "SAFE" module reloading, meaning: when we rehash (reload a module) we don't close the old module handle (dlclose) and then open the new one (dlopen), no.. we KEEP the old one open and THEN open a new one and do some checks and if they pass the old one is closed. This makes sure that not something odd can happen between closing the old one and opening the new one(eg: out of fds, or.. well several possibilities). In contrast to MANY other software, which does not do this... I hope inspircd is not one of them, anope is I think.. That's the only reason for hardlink and/or copy, it's to fool the dl loader which will otherwise NOT load the new module because it knows the old one is still in memory and THINKS it's the same (reference count...), even though it's not... Oh and yes, I suppose it also helps against overwrites, such as someone compiling or copying things over, but that's just an extra bonus. So, if you removed the copy-or-hardlink-before-load, then you just broke the upgrade-on-the-fly capability.
(0015337) w00t    2008-08-04 08:59	Oh, I wasn't aware you tried to reload everything on a /rehash, we don't do that as it would be way, way too slow with the number of modules we have (and, as you've observed, because we don't have a /tmp copy). Instead, on rehash, two lists are generated; modules which have been unloaded - as well as ones that have been loaded. Those two are processed, anything not on those lists isn't touched. To 'upgrade on the fly', /reloadmodule m_blah.so or /unloadmodule and /reloadmodule are required.
(0015898) Stealth    2009-07-24 01:21	Is this still an issue? Or did we determine this is entirely to do with Gentoo's ports?
(0015925) syzop    2009-08-17 11:49	implementing this breaks things rather than solving anything :P.
(0016307) ohnobinki    2010-08-23 19:02	May this be made compile-time configurable to support hardened systems? If someone is running Gentoo hardened and does a /rehash, there is no need to reload modules because none of them will have changed. Also, perhaps there is a more correct way to force libdl to reload a library.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3946	[unreal] ircd	feature	always	2010-08-22 21:15	2010-08-23 07:12
Reporter:	tabrisnet	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	confirmed	Product Version:	3.2.8
Product Build:		Resolution:	open
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	CS INVITE noisy due to ircd invite notice
Description:	Implemented a CS JOIN that calls CS INVITE (if user has access), so that a JOIN may always succeed (regardless of +i, +k, +b, etc). Unfortunately every time a user with access uses CS JOIN (NS AJOIN uses CS JOIN), an invite notice is sent to the channel. For some channels, this is considered annoying. Can we add a SVSINVITE that doesn't do this, or make a configurable option to disable the notice?
Steps To Reproduce:
Additional Information:
Attached Files:	unreal-3946-no-invite-channotice.patch (1 KB) 2010-08-23 07:11

Notes
(0016300) ohnobinki    2010-08-23 05:11	I think that this has come up before, with the correct solution being use of some invite numeric instead of an invite notice.
(0016301) ohnobinki    2010-08-23 07:11	unreal-3946-no-invite-channotice.patch: I think that this is the correct way to inform channel members (ops only) of channel invites.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3794	[unreal] installing	minor	always	2009-01-14 22:51	2010-08-20 16:02
Reporter:	ohnobinki	Platform:	amd64
Assigned To:	ohnobinki	OS:	Gentoo
Priority:	normal	OS Version:	2.0
Status:	resolved	Product Version:	3.2.7
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	missing aclocal files
Description:	When I enter into the automake directory and run "autoreconf -vfi ..", the configure file is created. However, I get the following in the output of ./configure: checking for size_t... yes checking whether time.h and sys/time.h may both be included... yes checking whether struct tm is in sys/time.h or time.h... time.h checking for uid_t in sys/types.h... yes ./configure: line 6052: unreal_CHECK_TYPE_SIZES: command not found checking what kind of nonblocking sockets you have... O_NONBLOCK checking whether x86_64-pc-linux-gnu-gcc needs -traditional... no checking whether setpgrp takes no argument... yes I found that this macro is defined inside of aclocal.m4, but running aclocal tries to regenerate aclocal.m4 and the definition of unreal_CHECK_TYPE_SIZES is not included in the .tar.gz. I checked out the 3.2.8-rc1 .tar.gz file and found the same problem.
Steps To Reproduce:
Additional Information:	I am interested in being able to modify configure.in and completely regenerate all of the generated autoconf/automake/autowhatever files:-). Thanks for any help.
System Description
Attached Files:

Notes
(0015656) ohnobinki    2009-01-15 02:54	another autoconf macro which isn't included in the tarballwell, : checking for inflateEnd in -lz... (cached) yes checking zlib in /usr... ok ./configure: line 10857: CHECK_LIBCURL: command not found checking if FD_SETSIZE is large enough to allow 1024 file descriptors... yes checking for TRE... yes extracting c-ares resolver library
(0015686) ohnobinki    2009-01-18 19:20	I'd like to extend this bug to be a request for all source files to be added to the tarballs/repository. I'm not sure where to find files like Makefile.am or configure.ac. Is there a place that they are published? Providing these and related files as part of the tarball would aid people who want to hack the UnrealIRCD code.
(0015689) Stealth    2009-01-18 21:25	It's not necessary for these files to be included in the tarball. If you would like them, you can get them from the CVS repository.
(0015800) ohnobinki    2009-02-23 16:53	I can not find the CVS repository. I found the SVN repository and looked for such files (*.ac, *.am) , but none existed. Are there instructions somewhere for updating the autoconf/automake files?
(0015818) ohnobinki    2009-03-04 00:38	I have finally realized that unrealircd doesn't use automake, so I guess the request for *.am files is incorrect. However, I still have difficulty running aclocal; autoconf because I have to rename aclocal.m4 to acinclude.m4 to get aclocal to see your macros. I guess this bug is reduced to a request that you change the name of aclocal.m4 to acinclude.m4 :-).
(0016297) ohnobinki    2010-08-20 16:02	with the restructuring of ./configure.ac and advent autoconf/m4 and ./autogen.sh, I think what I complained about in this bug is fix.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3329	[unreal] ircd	minor	always	2007-05-11 00:44	2010-08-20 13:17
Reporter:	Bock	Platform:	i386
Assigned To:	ohnobinki	OS:	all
Priority:	normal	OS Version:	all
Status:	resolved	Product Version:	3.2.6
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	Not unsetting all modes on /umode2 -o
Description:	I think then I deoper myself, usermode +s must be unset too. from conf:     modes-on-oper "+wgs";     restrict-usermodes "skB"; on oper: [08:38:27] ::: Mode change [+oghaAsNW] for user wx|wrk [08:38:27] ::: Server notice mask (+kfjveGqSso) [08:38:27] ::: You are now an IRC Operator on umode2 -o: [08:38:35] ::: Mode change [-oghaANW] for user wx|wrk [08:38:35] ::: Server notice mask (+ks) I think that on umode2 -o: must be : Mode change [-oghaAsNW] for user wx|wrk
Steps To Reproduce:
Additional Information:
Attached Files:	unreal-3329-deoper-remove-snomask.patch (2 KB) 2010-08-19 05:39

Notes
(0014089) aquanight    2007-05-11 09:41    (edited on: 2007-05-11 09:42)	Keep in mind +s is allowed for nonopers by default. However, if you've put s in restrict-usermodes, it really should indeed be removed (since it's effectively an "oper-only" mode). Same for all usermodes listed there. Dunno if that's what happens or not. (edit: and I now notice you do indeed have it in restrict-usermodes, so...)
(0014090) Stealth    2007-05-11 14:20	perhaps on deoper have Unreal check for restricted-usermodes NOT in set-modes on connect, and remove those
(0014092) Bock    2007-05-11 15:36	+1 to Bugz
(0016175) syzop    2010-07-14 17:34	Sounds like something quite easy to fix, check if s in there, and remove s. Is a slight security issue (ok, that's maybe a bit exaggerated) if this won't get fixed --> 3.2.9.
(0016214) vonitsanet    2010-07-18 16:35    (edited on: 2010-07-18 16:51)	Correct me if i'm wrong.. Is this command supposed to be used by clients? I remember someone who wrote (years ago, so i don't remember details) that umode2 is for another purpose.
(0016215) syzop    2010-07-18 17:12	Yea I don't care too much about umode2, but.. I'm assuming the same issue exists with MODE $nick -o as well.
(0016285) ohnobinki    2010-08-19 04:38	OK, so would the fix be to remove s if and only if both of the following are satisfied? - s is in restrict-usermodes - s is in modes-on-oper
(0016286) ohnobinki    2010-08-19 05:02	oh,and: - s is not in modes-on-connect
(0016287) ohnobinki    2010-08-19 05:27	Seems that whether or not modes-on-oper contains `s' has no bearing on whether or not opering up will give the oper a snomask, thus we are left with: - s is in restrict-usermodes - s is not in modes-on-connect
(0016288) Bock    2010-08-19 07:35	In our config:     modes-on-connect "+wi";     modes-on-oper "+wgs";     restrict-usermodes "skB";
(0016289) syzop    2010-08-19 17:26	ohnobinki: Yup, exactly.
(0016293) ohnobinki    2010-08-20 13:16	Interpreting that as a ``go ahead and commit'' ;-). - Remove snomasks upon deopering when it seems like the user shouldn't have snomasks. (0003329)

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3053	[unreal] ircd	tweak	N/A	2006-09-04 11:45	2010-08-20 13:11
Reporter:	Stealth	Platform:	*
Assigned To:	ohnobinki	OS:	*
Priority:	normal	OS Version:	*
Status:	resolved	Product Version:	3.2.6
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	Warning when running as root
Description:	If Unreal is started as root, I think it would be great to have it print a warning and have the user enter a confirmation. Maybe have the user say it is OK once like X-Chat does. Such as: WARNING: Running Unreal as root is bad! Start anyway? (yes/no):
Steps To Reproduce:
Additional Information:
System Description
Attached Files:	unreal-3053-warn-root.patch (2 KB) 2010-08-20 05:53

Notes
(0012307) codemastr    2006-09-04 12:48	X-Chat is a client program. Unreal is a daemon. A daemon shouldn't ask questions like that. For example, consider having a script that starts Unreal. It will now hang waiting for someone to type "y". I agree, you shouldn't run Unreal as root, but I think this is a bad way to solve the problem. The more questions an IRCd has to ask, the more difficult it is to automate.
(0012308) Stealth    2006-09-04 14:11	That's why it only asks once... It can store the yes result in the tune file or smth
(0012309) pinstrate    2006-09-04 15:47	I promise I'll write a patch to remove this stuff from the core if it will be added. Behave like all other ircds - just warn but nothing more!
(0012310) aquanight    2006-09-04 16:37	Also there are reasons that it may be necessary for unreal to boot as root, chroot and setuid/setgid to name a few (though this then gets to crazy interactions with /rehash, /restart and such). Also the pedants who want to use the IANA IRC port (194 I think?) that's in the privileged range have to start unreal as root (and setuid probably doesn't work in that case). Look at most of the other common daemons (syslog, sshd, httpd, ftpd, ntpd, cron, etc). How many of them ask "Are you sure you want to start this daemon as root?" on /dev/console first time you start your system? That would be bad for a headless system.
(0012311) syzop    2006-09-04 16:57	Warning? Sure. But not if IRC_UID is defined and > 0. Prompt or anything else? No.
(0012348) djGrrr    2006-09-07 21:27	IANA IRC port (194 I think?) <-- technically you don't need to start as root for that, as you can setup a firewall rule to say, forward port 194 (a virtual forward to the same box) to something higher like 6667. Most if not all firewall packages for *nix and *bsd support this in some way shape or form, and its actually quite useful in situations like that :)
(0012359) pinstrate    2006-09-08 01:48	stupid idea actually.. You flush your fw and everyone is connection reset by peer or ping timeout.
(0012360) djGrrr    2006-09-08 08:34	And for what reason would you ever flush your firewall ? This wouldn't be for someone who doesn't know what they are doing.... If you have it setup correctly, flushing your firewall doesn't disconnect existing connections, it would just deny new connections to the virtual port. *most* people aren't exactly in the habbit of flushing their firewall if its going to cause disconnections....
(0016185) syzop    2010-07-14 21:01	I think we can resurrect this idea again ;) See my (2006) comment: add a (clear) warning, but don't warn if IRC_UID (or IRC_USER nowadays?) is in use (coz it will setuid...).
(0016290) ohnobinki    2010-08-20 05:53	unreal-3053-warn-root.patch: Warns users if they are starting UnrealIRCd as root and seteuid() is not enabled. Tested with IRC_USER and IRC_GROUP set and unset, seems to work.
(0016291) syzop    2010-08-20 11:09	Looks good. Though, you might want to mention something about setting IRC_USER in include/config.h in the error message. Basically, give a suggestion of what the user should do: 'Either start the IRCd as another user than root, or properly set IRC_USER in include/config.h'.. something like that...
(0016292) ohnobinki    2010-08-20 13:11	OK, the text has been lengthened to include those instructions and committed. - Warn users against running UnrealIRCd as root without setting IRC_USER. (0003053 reported by Stealth)

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3189	[unreal] ircd	minor	always	2007-01-04 21:17	2010-08-19 03:06
Reporter:	TommyTheKid	Platform:	ppc
Assigned To:	ohnobinki	OS:	Mac OSX
Priority:	normal	OS Version:	10.4.8
Status:	resolved	Product Version:	3.2.6
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	improper use of mode_t for DEFAULT_PERMISSIONS in chmod and open operations
Description:	For some reason, on the mac, ./include/setup.h has a line: #define DEFAULT_PERMISSIONS 600 (its missing the leading zero) .. I am not sure *why* that happens, or whether it affects more than just OSX 10.4, but it lead to me discovering that putting 0600 is not really a proper use of "mode_t" for chmod/open operations. As per the following man page... [man 2 chmod] CHMOD(2) BSD System Calls Manual CHMOD(2) NAME      chmod, fchmod -- change mode of file SYNOPSIS      #include <sys/types.h>      #include <sys/stat.h>      int      chmod(const char *path, mode_t mode);      int      fchmod(int fd, mode_t mode); DESCRIPTION      The function chmod() sets the file permission bits of the file specified      by the pathname path to mode. Fchmod() sets the permission bits of the      specified file descriptor fd. Chmod() verifies that the process owner      (user) either owns the file specified by path (or fd), or is the super-      user. A mode is created from or'd permission bit masks defined in      <sys/stat.h>:            #define S_IRWXU 0000700 /* RWX mask for owner */            #define S_IRUSR 0000400 /* R for owner */            #define S_IWUSR 0000200 /* W for owner */            #define S_IXUSR 0000100 /* X for owner */            #define S_IRWXG 0000070 /* RWX mask for group */            #define S_IRGRP 0000040 /* R for group */            #define S_IWGRP 0000020 /* W for group */            #define S_IXGRP 0000010 /* X for group */            #define S_IRWXO 0000007 /* RWX mask for other */            #define S_IROTH 0000004 /* R for other */            #define S_IWOTH 0000002 /* W for other */            #define S_IXOTH 0000001 /* X for other */            #define S_ISUID 0004000 /* set user id on execution */            #define S_ISGID 0002000 /* set group id on execution */            #define S_ISVTX 0001000 /* save swapped text even after use */ [snip] (this was from Mac OSX, but Linux, Solaris and others have extremely similar information) ... DEFAULT_PERMISSIONS should be defined as: #define DEFAULT_PERMISSIONS (S_IRUSR|S_IWUSR) ** this might even allow the "DEFAULT_PERMISSIONS" to work on other OS's like "d0ze" ?
Steps To Reproduce:	on OSX? maybe others? run ./Confg (select defaults) .. verify as the system runs ./configure, there is a --with-permissions=0600 .. somewhere during ./configure, the leading zero gets lost (at least on Mac OSX) look at ./include/setup.h, if DEFAULT_PERMISSIONS is "600" and not "0600" ircd will not start, cause it will chmod your unrealircd.conf file to look like: ---x-wx--T 1 ircdev ircdev 3665 Jan 4 18:17 unrealircd.conf .. which is not readable. ---x-wx--T -> 1130  ... curiously if you do printf("%o\n", 600); you get 1130 :)
Additional Information:
Attached Files:	configure.patch (0 KB) 2007-01-05 12:10

Notes
(0012998) TommyTheKid    2007-01-04 21:20	ugh, for what its worth, you can specify "0" for the default permissions to work around this, or modify ./include/setup.h to add the leading zero to the DEFAULT_PERMISSIONS.. or if you desire, properly define it (S_IRUSR|S_IWUSR) ~tommy
(0013001) stskeeps    2007-01-05 04:09	0600 points out it's octal in C - i noticed this some weeks ago myself. Try printf("%i %i\n", 0600, 600)
(0013005) TommyTheKid    2007-01-05 11:12	For those that have not figured this out, and I meant to paste this output above... HERE is what it looks like when this bug manifests itself. $ ./unreal start Starting UnrealIRCd  _ _ _ ___________ _____ _ | | | | | |_ _| ___ \/ __ \ | | | | | |_ __ _ __ ___ __ _| | | | | |_/ /| / \/ __| | | | | | '_ \| '__/ _ \/ _` | | | | | / | | / _` | | |_| | | | | | | __/ (_| | |_| |_| |\ \ | \__/\ (_| |  \___/|_| |_|_| \___|\__,_|_|\___/\_| \_| \____/\__,_|                            v3.2.6                      using TRE 0.7.2 (GPL)                      using OpenSSL 0.9.7l 28 Sep 2006 * Loading IRCd configuration .. [error] Couldn't open "unrealircd.conf": Permission denied [error] Could not load config file unrealircd.conf [error] IRCd configuration failed to load Possible error encountered (IRCd seemingly not started) ===================================================== Check above for possible errors, and this output of ircd.log. If you cannot solve the problem, read Unreal.nfo on where to get support ===================================================== [Thu Jan 4 19:34:23 2007] - TIME SYNCH: timeserver=1167968063, our=1167968063, offset = 0 [old offset: 0] $ ls -l unrealircd.conf ---x-wx--T 1 ircdev ircdev 3665 Jan 5 09:05 unrealircd.conf Again, this is due to the (shell|autoconf|somethingelse?) treating the --with-permissions=0600 like a regular (decimal) number and "simplifying" it to 600 on assignment to the variable $with-permissions (which for some reason is assigned to $withval) and added to the .h file incorrectly during the configure script. http://www.google.com/search?q=600+in+octal [^] 600 = 0o1130 ~tommy
(0013006) TommyTheKid    2007-01-05 12:14	I have included a temporary patch (configure.patch) that changes one line in ./configure (slightly modified to make more sense and protect the innocent) [10:53:50] <TommyTheKid> ac_optarg=`expr "x$ac_option" : 'x[^=]*=\(.*\)'` <-- there is where it gets botched [10:54:16] <TommyTheKid> mini:~ ircdev$ ac_optarg=`expr "x$ac_option" : 'x[^=]*=\(.*\)'` [10:54:16] <TommyTheKid> mini:~ ircdev$ echo $ac_optarg [10:54:16] <TommyTheKid> 600 [10:54:16] <TommyTheKid> mini:~ ircdev$ echo $ac_option [10:54:16] <TommyTheKid> --with-permissions=0600 [10:54:48] <satmd> it's the expr in there [10:56:24] <satmd> how about echo "x$ac_option" | sed 's,x[^=]*=\(.*\),\1,' ? [10:57:11] <satmd> TommyTheKid's expr isn't broken [10:57:18] <satmd> it just handles numbers as numbers [10:57:25] <satmd> - stripping leading zeros [10:57:29] <TommyTheKid> satmd: it does work (come up with 0600) [10:57:31] <satmd> :) [10:58:07] <satmd> would you please submit it as a bug and include it in patch format? *** This resolves the "issue" that I am experiencing, and should probably work OK for most POSIX complaint machines, but at some point someone should look into the proper use of chmod(2) ~tommy
(0013010) syzop    2007-01-06 15:51	Yes this is an OS X bug. I think I heard about it before (don't know if it was ever reported, though).
(0016178) syzop    2010-07-14 17:53	We should fix this in 3.2.9, or was this already addressed? There were some mac fixed in the past few years... might even be fixed before 3.2.8? Note that part of the bug is the missing 0 (somehow), and not something like a bad syscall/function.
(0016182) ohnobinki    2010-07-14 18:42	I just tested CVS and 3.2.8.1 on Mac OSX 10.5.8 and this issue still exists. From satmd's patch, I wonder if this is an autoconf bug.
(0016283) ohnobinki    2010-08-17 19:22	I know that satmd wrote essentially the following somewhere, but I want to record it for myself here. The problem is a bug in Mac OSX's expr(1) program: peter-krakers-mac-mini:unreal binki$ /bin/expr X--enable-permissions=0660 : '[^=]*\(.*\)' =0660 peter-krakers-mac-mini:unreal binki$ /bin/expr X--enable-permissions=0660 : '[^=]*=\(.*\)' 660
(0016284) ohnobinki    2010-08-19 03:06	I filed a bug against Mac OSX, but I think the below solution is better for two reasons. First, it should stop this problem from happening on Mac OSX -- including old versions (even if a new OS X actually was fixed by Apple...). Secondly, it will act like chmod(1) which users are more used to using (where chmod 600 myfile is the same as chmod 0600 myfile). I'm quite sure that an extra zero in front of the value (i.e., 0600 now becomes 00600 on Linux or machines with non-buggy expr(1) programs) can't possibly cause anyone harm ;-). - Prepend a `0' to the begining of --with-permission, working around a Mac OS X bug and hiding the fact that chmod()'s params are octal from users. (0003189)

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3944	[unreal] ircd	minor	always	2010-08-15 20:02	2010-08-16 11:33
Reporter:	Jobe1986	Platform:	x86
Assigned To:	syzop	OS:	FreeBSD
Priority:	normal	OS Version:	7.0
Status:	resolved	Product Version:	3.2.8
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	FreeBSD, IPv6 build, IPv4 listen blocks and *:port listen blocks
Description:	OK, today I found a few issues with using UnrealIRCd 3.2.8.1 on FreeBSD 7.0 with IPv6 support enabled. Those issues are: A) "listen *:6667;" only listens on IPv6 IP's (http://bugs.unrealircd.org/view.php?id=2741 [^] suggests a solution that requires root which isnt an option for everyone) B) A listen block specifying an IPv4 IP (both "1.2.3.4:6667" and "[::ffff:1.2.3.4]:6667" forms) fails with an error suggesting another solution, once again requiring root. So having found a solution that does not require root, I have attached a .diff with a solution to BOTH issues.
Steps To Reproduce:
Additional Information:
Attached Files:	unreal-ipv6-bsd.diff (0 KB) 2010-08-15 20:02

Notes
(0016274) warg    2010-08-15 20:05	I like this ++
(0016275) syzop    2010-08-15 21:09	This is already in latest CVS ;) #if defined(INET6) && defined(IPV6_V6ONLY)         /* We deal with both IPv4 and IPv6 in one (listen) socket.          * This used to be on by default, but FreeBSD, and much later Linux          * sometimes as well, seem to default it to IPv6 only ('1').          * We now have this new fancy option to turn it off in Unreal,          * instead of requiring our users to sysctl.          */         opt = 0;         if (setsockopt(fd, IPPROTO_IPV6, IPV6_V6ONLY, (OPT_TYPE *)&opt,             sizeof(opt)) < 0)                         report_error("setsockopt(IPV6_V6ONLY) %s:%s", cptr); #endif Anyway, I never got an opportunity to test it. But it works?
(0016276) ohnobinki    2010-08-15 22:08	This code is already in CVS. One note I'd like to make, however, is that on certain installations, setsockopt() _does_ return nonzero and spits a bunch of ``setsockopt(IPV6_V6ONLY)'' errors into ircd.log when it seems that there is no need to report such an error. (i.e., the setsockopt() call fails even though the IPv4 over IPv6 stuff is working find).
(0016277) ohnobinki    2010-08-15 22:11	Ugh, I should'nt've touched this bug, I've only messed up its state :-/.
(0016278) Jobe1986    2010-08-15 22:26    (edited on: 2010-08-15 22:27)	Yes this does work on FreeBSD 7.0. But it is worth noting that this will not work on Windows due to Windows lack of dual stack support. So in case you haven't already (your paste didn't mention it) you should make sure this fix only applies to non-windows builds at the very least. As for already being in CVS, I suppose I really should have checked first. :P
(0016282) syzop    2010-08-16 11:33	Ok, glad to hear it actually works :) Jobe: as for windows, we don't support IPv6 on windows, see 0000008 ohnobinki: good point, now got rid of any possible warning in CVS .868: - Get rid of any setsockopt(IPV6_V6ONLY) errors in ircd.log (0003944).

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2620	[unreal] installing	tweak	N/A	2005-08-15 07:05	2010-08-16 04:30
Reporter:	pinstrate	Platform:
Assigned To:	ohnobinki	OS:	unix-like
Priority:	normal	OS Version:	all OSes
Status:	resolved	Product Version:	3.2.4
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	copying ircdcron/ircdchk to the destination dir with `make install`
Description:	I think that it would be a good idea if the whole ircdcron or at least ircdcron/ircdchk file would be copied to the destination directory when make install'ing. this would: *ensure that the script will still check (if added to cron, of course) if ircd is alive even if something happens with source directory (eg. gets removed, overwritten and so on) *save some manual copy'ing :) Let's say I often like to dowload cvs version and install it.. here are the steps I do: rm -rf /home/my/unreal-cvs-dir wget the_latest_cvs ./Config and make then rm -rf /home/my/irc.server.net dir make install *then* each time I have manually copy the ircdcron dir to my /home/my/irc.server.net directory.. It would be nice if Unreal would do it automatically :)
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0010334) pinstrate    2005-08-15 07:06	Sorry, forgot to mention about copying my *.conf files back to the server's directory, but that is not a big issue I think.
(0016186) syzop    2010-07-14 21:04	We should do this (copying on make install). I did not really verify if this was already fixed, though... a quick grep suggests it isn't.
(0016281) ohnobinki    2010-08-16 04:30	- Install ircdcron scripts. (0002620) - Autogenerate ircdcron/ircd.cron based on ./configure settings.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3916	[unreal] ircd	minor	N/A	2010-07-05 13:22	2010-08-16 04:13
Reporter:	syzop	Platform:
Assigned To:	ohnobinki	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	upgrade TRE
Description:	upgrade tre to 0.8.0 and do much testing...
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0016257) syzop    2010-08-08 20:25	unassigned (for now). I'm fine if you'd like to do this, binki...
(0016279) ohnobinki    2010-08-16 02:57	I've already done the hack I mentioned above for c-ares, so I might as well do the same for libtre.
(0016280) ohnobinki    2010-08-16 04:13	- Upgrade to tre-0.8.0, adding hack similar to the one for c-ares to ensure that the bundled tre is compiled against even when a system libtre is installed. (0003916) Concerning the much testing: I don't yet have any methodologies to stress-test the regexp-reliant portions of unrealircd (such as spamfilter). I think it's best to just commit this now and hope that possible bugs show up for CVS users. I know that I've had no trouble compiling or running unrealircd against a system-installed libtre-0.8.0 on my lappy. I know that the API hasn't changed as the API is POSIX-compatible (and thus the ABI couldn't've really changed). Thus, I don't anticipate any tre-0.8.0-related problems ;-).

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2321	[unreal] ircd	minor	always	2005-02-03 21:21	2010-08-15 06:51
Reporter:	syzop	Platform:
Assigned To:	ohnobinki	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	ipv6 clones checking
Description:	AFAIK we don't have this, but I think it's kinda needed: we shouldn't be checking for clones on ipv6 addresses with an *EXACT* IP, but rather on.. well, I forgot, but.. say /64, like most ipv6 ircds do. Else someone can easily launch like 1000+ clones, and if no oper is present (even if just for a few minutes) you can have not-so-nice-effects :p.
Steps To Reproduce:
Additional Information:
Attached Files:	unreal-2321-ipv6-clones.patch (11 KB) 2010-08-13 06:52 unreal-2321-ipv6-clones-r1.patch (11 KB) 2010-08-13 16:34

Notes
(0009024) codemastr    2005-02-04 00:27	Yeah, I guess that's a good idea.
(0010617) stskeeps    2005-10-30 13:20	that's a bit problematic, since part of that can be encapsulated MAC address, which will be used A LOT in future IPv6 setups. We should invent filters/modules for noticing a sudden rise in connections from certain subnets instead. Perhaps something to kill mirkforce things too?
(0016134) syzop    2010-07-02 10:01	got reminded by this by someone in #unreal-support. Technically, no problem to implement this. Just need to think on how to do it configuration-wise (unrealircd.conf). As not everyone would want to limit per /whatever CIDR mask, some would still want to limit by-ip like now. There are two options I can think of: 1) Global setting, of what is considered an ipv6 clone 2) Per-class setting Since you might want to make a distinction between clone settings per-netmask, the per-class would be needed. Like, one subnet might have many with per-ip (->special class), while you would like to do per-netmask for all others (->regular client class). Actually, how about doing both? Having a global setting which is the default for all classes, which can be overridden in each class. Now as for the name... hmmm.. ipv6-clones-netmask, or something with cidr or bitmask... set::ipv6-clones-bitmask 32; not sure.. I'm open for suggestions. since this only takes little coding to implement and might be quite an issue in some cases I think we should implement this for 3.2.9, if possible.
(0016161) tabrisnet    2010-07-14 16:59	As the policy from various RIRs is that allocation to end-point (residential) will be /64, and to corporate entities will be /48, making the bitmask 32 is highly unlikely, albeit I wouldn't recommend making there be a minimum size of the mask as much as that we should make it clear in the docs that due to the RIR rules...
(0016167) syzop    2010-07-14 17:13	I just picked a random value of 32 in my example, if that's what you mean :) But what's your opinion on the general idea? This issue is not 100% Release Critical, but is high on my "3.2.9 should have this" list.
(0016169) tabrisnet    2010-07-14 17:19	No objection to the idea... hell, I'd expand it a bit and by default HIDE the bottom 64 bits including from the cloak. So then one only looks at the top 64 bits for purposes of channel bans & clone counting. Not to say that we should drop the lower 64bits altogether if they umode -x, or hide it from opers.
(0016258) ohnobinki    2010-08-11 05:41	So far for config naming, my thoughts are: /* default of 96, assuming that most people have their own 32 bits */ set::default-ipv6-clones-mask 96; /*  * the allow blocks would default to set::default-ipv6-clones-mask.  * they would have the option below to override the default.  */ allow::ipv6-clones-mask <set::default-ipv6-clones-mask>; For the masks, I would give the user an error if they set the mask to 0 and a warning if it was <= 32. Should I probably warn for <= 64? syzop: Disallowing 0 would not hurt anyone and would be one way to implement a default allow::ipv6-clones-mask. (If the user doesn't set the allow::ipv6-clones-mask, I could set the variable to 0. After the entire config file is parsed, I would check for allow blocks that have a value of 0 and replace it with the set::default-ipv6-clones-mask. Is this the best/proper way to implement overridable defaults for this case? ;-) ).
(0016259) syzop    2010-08-11 16:44	Sure, sounds fine. If I understand correctly, if one would set it to 128 you get the current behavior, right? Just making sure that's still permitted, without warning. The warning would be just there when illogical configuration is encountered. I wouldn't mind us setting a default for set::default-ipv6-clones-mask, of like 96... [that would be done in config_setdefaultsettings()] Yes, the way you describe would indeed be the way to go with regards to setting the allow::ipv6-clones-mask with the set::default-ipv6-clones-mask if the allow:: one is not set. And yes, I don't see why to permit 0 either ;)
(0016260) tabrisnet    2010-08-11 16:53	I think there are only 2 sane defaults: 64 and 128. I'm not aware of _any_ RIR that has a policy that ISPs should hand out longer prefixes than /64. Yes, I agree that a /64 is ridiculous, no one could ever use that much address space and a /96 would be more sensible... But the regulations from ARIN (and presumably other RIRs) remain. Btw, what does this do to cloaking? How are the bits divided among the various components of the cloaks? I know that for IPv4 it was 16/8/8. If your plan goes something like 16/16/16/16/64, that would probably be reasonable. But I don't seem to remember an IPv6 cloak being that long.
(0016261) ohnobinki    2010-08-11 17:56	> If I understand correctly, if one would set it to 128 you get the current behavior, right? Yes, this is perfectly valid. I intend to put this as an example in the documentation when I get this functional. > I wouldn't mind us setting a default for set::default-ipv6-clones-mask, of like 96... [that would be done in config_setdefaultsettings()] That's actually about all the progress I made last night ;-). > Btw, what does this do to cloaking? As far as I understand, this bug doesn't have anything to do with cloaking or channel bans. It just affects the code that enforces allow::maxperip. (at least, so far...)
(0016262) syzop    2010-08-12 11:52	Ok, as for the default value for set::default-ipv6-clones-mask: users/admins usually get a /80 (which they subnet themselves to /64) or a /64 directly, right? So then 64 would be a good default? As for cloaking, that is indeed not what this bugreport is about. tabrisnet: if you would like to put in a request for that, you'd have to open up a new one.
(0016263) ohnobinki    2010-08-13 06:56	unreal-2321-ipv6-clones.patch: my first complete try at doing this. Tested with ipv6-clones-mask of 128 and 127 and by adding loopback addresses (for 127, ::2 and ::3 overlap, another set of overlapping addresses would be ::12 and ::13). I changed the defaults mask to 64 bits. I poked at the docs. Unfortunately, this change leaves AllowClient() in a less readable state. Any comments more than welcome :-).
(0016264) syzop    2010-08-13 11:00    (edited on: 2010-08-13 11:01)	I was just taking a quick look, so I might overlook something, but... the stuff with ipv6_mask_addr in AllowClient(): +#ifdef INET6 + is_ipv4 = IN6_IS_ADDR_V4MAPPED(&cptr->ip); + + if(is_ipv4) + { + /* + * initialize a mask for IPv6 clones detection. It has + * to be zeroed out after aconf->ipv6_clone_mask + * bits. Code inspired by match_ipv6(). + */ + memset(&ipv6_mask_addr, 0, sizeof(ipv6_mask_addr)); + i = aconf->ipv6_clone_mask / 8; + memcpy(&ipv6_mask_addr, &cptr->ip, i); + /* support ipv6_clone_mask not being a multiple of 8 */ + ipv6_mask_addr.s6_addr[i] |= + ~((1 << (8 - aconf->ipv6_clone_mask % 8)) - 1) & cptr->ip.s6_addr[i]; + } +#endif /* INET6 */ (after that) it doesn't seem to do anything with ipv6_mask_addr? So either it can be removed or something was forgotten :P. I think the former, since match_ipv6() does all the work? EDIT: obviously with 'removed' I mean the 'if(is_ipv4)' block, and not the setting of 'is_ipv4' ;) And something really tiny, but it would continue if I never mention it: I noticed you change 'i++' to 'i ++' here and there (same for errors ++), but since we use varname++ everywhere I would ask you not to (IOTW conform to current style) :) Other than that, patch looks good, I think. I didn't test it, but it looks clean, has docs, etc... good job. Yet another item smashed, working towards a release :P Now I should do something too...
(0016265) ohnobinki    2010-08-13 15:45	> (after that) it doesn't seem to do anything with ipv6_mask_addr? So either it can be removed or something was forgotten :P. This would be wonderful, but match_ipv6() only fixes up its first argument (addr), not its second argument (mask). It expects mask to be all zeros after the first number of bits specified by match_ipv6()'s third argument (bits). I actually realize that I had forgotten to tie in use of ipv6_mask_addr while waking up this morning ;-). Or that's at least the reason that I wrote that piece of code ;-). There is an alternative and cleaner method with patching match_ipv6() in cidr.c: @@ -311 +311,2 @@ - if ((addr->s6_addr[n] & ~((1 << (8 - m)) - 1)) == mask->s6_addr[n]) + if ((addr->s6_addr[n] & ~((1 << (8 - m)) - 1)) + == mask->s6_addr[n] & ~((1 << (8 - m)) - 1))) In fact, I'm going to get rid of the humungous blob you quoted in favor of this ;-). > I noticed you change 'i++' to 'i ++' here and there Oops, I didn't realize i++ was the style even though I saw it everywhere. Thanks for the review :-).
(0016266) ohnobinki    2010-08-13 16:35	unreal-2321-ipv6-clones-r1.patch: tested with mask of 127 and 96, I think this is ready to commit.
(0016267) syzop    2010-08-14 19:30	Fine I think? :)
(0016273) ohnobinki    2010-08-15 06:51	- IPv6 clones detection support (0002321). allow::ipv6-clone-mask determines the number of bits used when comparing two IPv6 addresses to determine if allow::maxperip is exceeded. This allows an admin to recognize that most IPv6 blocks are allocated to individuals, who might each get a /64 IPv6 block. set::default-ipv6-clone-mask defaults to 64 and provides default value for the allow blocks.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3193	[unreal] ircd	feature	always	2007-01-06 06:13	2010-08-14 20:42
Reporter:	Shining Phoenix	Platform:	i386
Assigned To:	aquanight	OS:	Linux
Priority:	normal	OS Version:	2.6.10-1.771_FC2
Status:	resolved	Product Version:	3.2.6
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	Enable some combinations of extbans
Description:	Extbans ~c and ~r are different ways of specifying users, ~n and ~q are different things to do to users. Some new combos could be: ~nc - Users in matching channel can('t) nickchange ~nr - Users with matching realname can('t) nickchange ~qc - Users in matching channel can('t) speak ~qr - Users with matching realname can('t) speak And if the new simple ewxtban I suggested was added: ~jc - Users in matching channel can('t) join ~jr - Users with matching realname can('t) join Nice, accurate little extbans. I think anyone who uses ~c and ~r extbans may use these as well :)
Steps To Reproduce:
Additional Information:
System Description	Unreal IRCd 3.2.7 3rd party modules:  m_uline - $Id: m_uline.c,v 1.13 2004/03/09 10:32:28 angrywolf Exp $ (Command /uline) [PERM] [3RD]  m_regexcept - v0.1 (ExtBan ~E) [PERM] [3RD]  m_hostforward - $Id: m_hostforward.c,v 1.0.2 2005/02/15 16:13:15 Special Exp $ (Forward users by hostmask to another channel) [PERM] [3RD]  courtroom_lite - $Id: courtroom_lite.c,v 1.4 2004/07/02 20:58:28 angrywolf Exp $ (Channel mode +U (courtrooms)) [PERM] [3RD]
Attached Files:

Notes
(0013008) Stealth    2007-01-06 11:54	That'd be nice
(0013020) Bricker    2007-01-06 21:28	this seems way over the top. imo write a module for it, i wouldnt stick it in the core
(0013022) Shining Phoenix    2007-01-07 00:55	Yeah, but we know how 3rd party modules cause problems =P I guess I could request a module for this /me wanders off to the forums
(0013032) aquanight    2007-01-08 13:42    (edited on: 2007-01-08 13:45)	I'd think it's a bit simpler to just do "chained" extbans. Basically as it is now, ~n and ~q just take a n!u@h mask, but we could just pass the mask right back to the ban parser, thus allowing something like: +b ~n:~c:#blah - anyone in #blah can't /nick +b ~q:~r:*lamer* - anyone with "lamer" in realname can't speak Note you wouldn't be able to do this the other way around: for example, ~c:~q:#blah wouldn't work. This could conceivably be done to any extban that would otherwise just take a normal n!u@h mask. Of course you could then do wierd but useless combinations like ~q:~n:~q:~n:~q:~q:~n:~n:~c:#blah(*) ... but not for me to tell people not to uselessly waste banspace if they really want to do that for some reason. Bricker: As it is now, you can't write a module for it - extbans are only allowed one character (another reason why "chaining" as stated above would work better), and you can't "override" extbans like you do commands. Also it wouldn't allow extending this to other extbans, like RegExcept, etc. And if you look at the extban.c code for ~q/~n - it's a change of exactly 1 function call for each of the two (from extban_is_banned_helper to just is_banned) so it's not a stupidly complicated change or anything. ( (*) == Useless because ~q:blah == match (blah) only during msg check, and ~n:blah == match (blah) only during nick change, so ~q:~n:blah == match (match (blah) only during nick change) only during msg check == can never match. ) [edit: I should also point out that a chained ban would likely also not work with extban that doesn't ban on the join/nick/msg basis (eg: syzop's textban module). Also I suppose it would be necessary for ~q/~n's "format convparam to forward to the sub-extban's convparam]
(0013077) Shining Phoenix    2007-01-21 22:58    (edited on: 2007-01-23 21:19)	*Ignore this suggested syntax, look at the next one* Hmm, I have an idea. What if a user could only set one mode at a time when using an extban? So, when the first parameter after the mode has a ~ in front: /mode #channel {+|-}<mode> ~<extbans> {extbanparam} {extbanparam} ... {n!u@h} And when the first parameter after the mode does not have a ~ in front, it is handled normally. That way, you could combine any number of extbans together, e.g. /mode #channel +b ~jr stupid_bot_script *!*@*.aol.com
(0013091) Stealth    2007-01-22 13:47	The problem with that, is all the extban params need to be in 1 ban param. Spaces separate params, so it would not work.
(0013092) Shining Phoenix    2007-01-23 02:42	Umm, read over my suggestion more closely. When someone sets an extban using this system, they can only set one ban mode at a time. Then, since there are no other mode parameters to confuse things, the extban parameters can be seperated by spaces.
(0013097) aquanight    2007-01-23 09:37	No. - It would most certainly break clients. Much more than extbans do already. - It's extra work for the mode parser when simpler solutions are available.
(0013098) Shining Phoenix    2007-01-23 21:08    (edited on: 2007-01-29 23:13)	*I keep coming up with new ideas, look further down* Hmm. mode # +b/e/I ~type1:param1:param2:~type2:param3:param4 So, "after the second colon, before the next :~" would be the definition of param2 in that, then having : within an extban param(e.g. IPv6), and having ~ in an extban param(e.g. ~#chan2) wouldn't be a problem. I'm fairly sure no extban parameter would have ~: in it.
(0013099) tabrisnet    2007-01-23 21:11	a) ~T or ~r could contain _any_ characters b) I back aquanight on this one.
(0013100) tabrisnet    2007-01-23 21:12	a) chaining ~n and ~q to the extbans sounds interesting. b) adding multiple parameters is a bit much, and likely impossible.
(0013101) Shining Phoenix    2007-01-23 21:17    (edited on: 2007-01-29 23:14)	Tabrisnet said: a) ~T or ~r could contain _any_ characters Hmm. 1. Don't allow a combo of T and/or r and/or c and/or f 2. Make sure their troublesome parameter is specified last. Then, the banned text would be "all the stuff after the colon after the ~T:", the banned realname would be "all the stuff after the ~r:", the banned channel would be "all the stuff after the ~c:", and the forwarded channel would be "all the stuff after the ~f:". ...that just disallowed nearly every combo there is... Or, only allow combos between any number of action extbans, and just one usermatching extban. e.g. ~nq:n!u@h ~jr:realname ~qc:@#lamers ~nqfC:#losers:202.156.345.765/32 <--usermatching param is all after last colon *More detail below*
(0013102) aquanight    2007-01-23 22:02    (edited on: 2007-01-23 22:10)	The rule has always been 1 mode has no more than 1 parameter. Only +f and +j break this rule, but they need to. +b does not need to because it's a list mode. People can take the time to do +bbbbbbbbbbbbeIeIo blah.... Also, ~c bans *CAN* start with a tilde. You can use a PREFIX= prefix to match users in the channel with that status or higher. ~r can start with tildes. ~T can start with tildes. If you start saying X ban type has to be last (and you can't core-side enforce that for ~T, it's module-provided, so now you have to somehow let the module say "has to be last"), you completely defeat the purpose of the whole thing. This is exactly why it should stay one extban per +b, no more. Plus now you have to parse something around something other than a space seperator. Basic IRC already takes care of parameters as it is, no need for +b to do extra logic. (Checking for ~, some letter, and : is easy enough, but having to strtok() loop over a :-seperated list is pushing it.) And what is the benefit of it anyway? You don't get any more or less banspace with it (banspace is limited by # of bans and by raw length), and it's simpler to do +bbbb ban1 ban2 ban3 ban4 (and some clients have a command to do it for you, and some might even break it up into multiple /modes if you go over 12 bans). Extended bans confuse clients enough since they know only of normal bans. Please let's *NOT* confuse them anymore with multiple parameter stuff. One mode, one parameter. It's worked so far, why break it? It's feasible to chain ~q: and ~n: (and ~j:) onto the other extbans. It's just taking the fact that they already do half the work of normal ban parsing (normal n!u@h), and changing *one* function call (and add forwarding logic in convparam) is enough to have the other half. It isn't feasible to go wild with it and start chaining X00 bans onto the one entry. [edit: Ick, looks like I was wrong: is_banned is what actually checks the entire banlist (not just one ban). But we could extract the check of the individual ban inside the loop into a function and then just use that.]
(0013103) Shining Phoenix    2007-01-23 23:12    (edited on: 2007-05-07 20:28)	Hmm. Make ban syntax(I know this is a clumsy way to show it): mode #chan {+|-}<b|e> {~<{action}{masktype}|{other}:>}<mask> All extbans would be either action, masktype or other. Put all extbans in modules perhaps? Where action currently is = j|n|q|jn|nq|jq Masktype currently is = C|E|r|c Other currently is = T {optional} <required> option1|option2
(0013127) Bricker    2007-01-27 17:04	jesus H christ! FIX IT ALREADY! ;P
(0013156) Shining Phoenix    2007-01-31 03:23    (edited on: 2007-01-31 03:24)	aquanight said: I'd think it's a bit simpler to just do "chained" extbans. Basically as it is now, ~n and ~q just take a n!u@h mask, but we could just pass the mask right back to the ban parser, thus allowing something like: +b ~n:~c:#blah - anyone in #blah can't /nick I say: Would +b ~n:~c:~#blah work?
(0013157) JasonTik    2007-02-01 18:12    (edited on: 2007-02-01 18:13)	This conversation is getting weird. I agree with aquanight. The ~q:~c:#Chan chaining stuff is the way to go. Also: A ~j: would be very nice. As it is, a normal ban is ~j & ~q
(0013158) Shining Phoenix    2007-02-01 20:34	Err, a normal ban is ~q, ~j and % or higher required to nickchange >.> Well, if you're sure about the chaining, ok. A lot of ~: to type =(
(0014028) Shining Phoenix    2007-05-07 20:33	*bump* Chained extbans would be a good feature, e.g. +b ~n:~c:~#lame_guys_channel Modules that provide extra extbans would need to be fixed afterwards to take advantage of this feature...especially m_hostforward (extban ~f). Disallowing colons in channel names, which I believe is going to be done in future, will make chained extbans more doable.
(0014045) syzop    2007-05-08 04:24	aquanight wanted to do this but, basically I said waaaaah waittt ;P But I'd be fine if you (aquanight) would again look into it... with a few remarks: * Things should stay very fast, ban checking is one of the most important CPU eating tasks in the IRCd (top 5). * The code shouldn't be cluttered too much, aka "try to keep the code nice" * There should be a config option to disable this feature (for speed/personal preferences/etc) * Should only allow one combination like ~q:~c:#chan and not like ~q:~c:~c and such ;p * You're right, be careful with allowing which extbans to be extended, sometimes ~ may be used in the extban itself already, so that means it could not be extended or else you get confusion. I guess extbans should somehow set a flag (on init/load/whatever, in the extbanadd thing) whether they'd allow them to be extended or not. ~q and ~n look a good place to start. So like point 1 (speed), if you'd split things to 'check whole banlist' and 'check individual ban' functions, be sure to tag the 2nd as inline, and.. also use the n!u@h buffers (std, ip, cloak, etc) in that function and don't go rebuild them for every ban... you get the idea. well, you probably get a good idea how to do things then, have fun ;P ***** Then on ~j.. that deserves a separate report, with some good explanation over there why it would be useful.
(0014083) Shining Phoenix    2007-05-10 21:54	~j at http://bugs.unrealircd.org/view.php?id=3192 [^]
(0014096) aquanight    2007-05-12 10:05	Going with the chained extban deal. To sum up what's basically going to happen: - Any extban (like, say, ~q) that normally uses (as either all or part of their parameter) a nick!user@host mask, can instead choose to allow sticking an extban in its place. So eg for ~q:nick!user@host, you could then do ~q:~c:#stfu. - It will be up to each extban to decide if it wishes to allow stacking extbans or not. The current extban_is_banned_helper() function that allows extbans to easily do n!u@h matching will remain as it is (= no extban stacking) for compatibility. - An extban that wishes to allow stacking will call a function like ban_check_mask, which will do n!u@h, or extban, as appropriate. Such extbans also need to arrange for convparam forwarding. - Since extbans are in control of whether or not extbans stack, they are given responsibility for dealing with any stacking limits they might want to impose, or to, say, collapse wasteful things like ~q:~q:~q:~q:~q:blah, to ~q:blah. - I'm still considering whether to control this behavior with a ./Config option or unrealircd.conf option, or indeed if such an option is really needed at all. I can understand the whole "personal preferences" deal though, and I'm leaning toward ./Config option since that way will ensure modules have to respect it (as if they don't, they won't compile when support for it is switched off :P ).
(0014121) aquanight    2007-05-13 17:19	Added to devel (3.3*) CVS, .2397 I'll do a slightly better write-up or something when I have time. Put simply, though, existing modules don't have to change unless they want to deal with chained extbans, but core extbans now support chaining. For compatibility, an Config option disables this support, and makes extbans work pretty much exactly as it did before. (So basically, modules can still support this and be ok in 3.2 because of the #define.) - Added support for "chained" extbans. Put simply this allows extban combinations   such as ~q:~c:#test to only silence users on #test, for example. This feature   is enabled by default, but can be disabled during ./Config -advanced. Module   support for this feature must note the following:   - For is_ok function, the extban can either assign extban_is_ok_nuh_extban, which     will deal checking a chained extban (including checking for restricted extbans),     or it can call that function from its own is_ok routine. For the latter case,     remember to pass only the mask part of your ban format (ie, don't just pass para as     otherwise it'll just call your is_ok again).   - For conv_param function, the extban can either assign extban_conv_param_nuh_or_extban,     which will automatically call conv_param for a chained extban, or pretty up a n!u@h mask.   - For is_banned, the extban should call ban_check_mask with the mask part of the parameter.     This will automatically call is_banned for a stacked extban, or match against a n!u@h. n!u@h     is checked against the current user (ie, with the info in the globals ban_ip, etc), so things     can get weird if you call this outside a normal ban check.   Modules must keep in mind that chained extban support is not available (and neither are the three   functions above) if DISABLE_STACKED_EXTBANS is #defined (this is controled by Config). Modules will   not compile/load if they try to use them anyway.   This change should not break extban modules, and should need some more extensive testing.
(0015399) Shining Phoenix    2008-09-03 04:21	The problem with combining extbans is that if you can combine some but not others, then you have to remember which can and can't be combined, which makes it more complex. If any extbans could be combined in one ban, then this topic gets simpler. If there was one magic character that could seperate the parameters of each extension, then you could do +b ~thing1:~thing2:param1<magic character>param2 An analogy for this is that the magic character in mode lines is a space, ie /mode #channel mode1mode2 thing1 thing2 The sticking point here is that I couldn't think of a suitable magic character for seperating the parameters of a chained ban. Today I think I figured it out. <magic character> is a semicolon As far as I know, semicolons are never in the host part of nick!ident@host, nicknames, CIDR bans or server names. So all that's left to worry about are channel names and real names. If semicolons are disallowed in channel names and real names, then semicolon won't be used within the matching bit of any extban (except T, I'll get to that later), so it can be used as the magic character. To diallow semicolons in real names, I suggest that ; gets changed to T, so that if a person has ;-; in their real name it changes to T.T, hence retaining its original meaning. Chaning textban ~T with other extbans is doomed to fail, so it simply shouldn't be allowed. So yeah, people would need to remember that T doesn't chain, but that's easier to remember than "c, C and r (and s if unreal has it) don't chain with each other".
(0016271) syzop    2010-08-14 20:41	Added in CVS mass-commit .863: - This is actually an update of earlier code from CVS, but now it works ok: - Added support for "stacked" extbans. Put simply this allows extban combinations   such as ~q:~c:#test to only silence users on #test, for example. This feature   is enabled by default, but can be disabled during ./Config -advanced.   This feature was suggested by Shining Phoenix (0003193), was then coded   by aquanight for U3.3, and later on backported and partially redone by Syzop.   Module coders:   In an extban ~x:~y:something where we call ~x the 1st, and ~y the 2nd extban:   Since stacked extbans only makes sense where the 1st one is an action   extended ban like ~q/~n/~j, most modules won't have to be changed, as   their extban never gets extended (just like ~c:~q: makes no sense).   However, you may still want to indicate in some cases that the extban your   module introduces also shouldn't be used as 2nd extban.   For example with a textban extban ~T it makes no sense to have ~n:~T.   The module can indicate this by setting EXTBOPT_NOSTACKCHILD in   the ExtbanInfo struct used by ExtbanAdd().   For completeness I note that action modifier extbans are indicated by   EXTBOPT_ACTMODIFIER. However, note that we currently assume all such   extbans use the extban_is_ok_nuh_extban and extban_conv_param_nuh_or_extban   functions. If you don't use these and use EXTBOPT_ACTMODIFIER, then things   will go wrong with regards to stack-counting.   Module coders should also note that stacked extbans are not available if   DISABLE_STACKED_EXTBANS is defined. - Added extended ban ~R:<nick>, which only matches if <nick> is a registered   user (has identified to services). This is really only useful in ban   exemptions, like: +e ~R:Nick would allow Nick to go through all bans if he   has identified to NickServ. This is often safer than using +e n!u@h. - Added Extended Invex. This is very much like extended bans, in fact it   supports some of the same flags. Syntax: +I ~character:mask   Currently supported are: ~c (channel), ~r (realname) and ~R (registered).   This can be useful when setting a channel invite only (+i) and then   setting invite exceptions such as +I ~c:#chan (or even ~c:+#chan), while   still being able to ban users.   Because action modifiers (~q/~n/~j) make no sense here, extended invex   stacking (+I ~a:~b:c) makes no sense either, and is not supported.   Suggested by DanPMK (0002817), parts based on patch from ohnobinki.   Module coders: set EXTBOPT_INVEX in the ExtbanInfo struct used by   ExtbanAdd() to indicate that your extban may also be used in +I. - Invex (+I) now always checks cloaked hosts as well. Just like with bans,   it checks them also when the user is not currently cloaked (eg: did -x, or   is currently using some VHOST). - Fixed client desynch caused by (un)banning, reported by Sephiroth (#2837).

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3928	[unreal] ircd	major	always	2010-07-14 17:32	2010-08-14 20:40
Reporter:	syzop	Platform:
Assigned To:	syzop	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	Fix chained/stacked bans
Description:	Just a TODO item to remember me fixing chained/stacked bans. It should not be in 3.2.9 release in it's current state.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0016270) syzop    2010-08-14 20:40	Fixed in CVS mass-commit .863: - This is actually an update of earlier code from CVS, but now it works ok: - Added support for "stacked" extbans. Put simply this allows extban combinations   such as ~q:~c:#test to only silence users on #test, for example. This feature   is enabled by default, but can be disabled during ./Config -advanced.   This feature was suggested by Shining Phoenix (0003193), was then coded   by aquanight for U3.3, and later on backported and partially redone by Syzop.   Module coders:   In an extban ~x:~y:something where we call ~x the 1st, and ~y the 2nd extban:   Since stacked extbans only makes sense where the 1st one is an action   extended ban like ~q/~n/~j, most modules won't have to be changed, as   their extban never gets extended (just like ~c:~q: makes no sense).   However, you may still want to indicate in some cases that the extban your   module introduces also shouldn't be used as 2nd extban.   For example with a textban extban ~T it makes no sense to have ~n:~T.   The module can indicate this by setting EXTBOPT_NOSTACKCHILD in   the ExtbanInfo struct used by ExtbanAdd().   For completeness I note that action modifier extbans are indicated by   EXTBOPT_ACTMODIFIER. However, note that we currently assume all such   extbans use the extban_is_ok_nuh_extban and extban_conv_param_nuh_or_extban   functions. If you don't use these and use EXTBOPT_ACTMODIFIER, then things   will go wrong with regards to stack-counting.   Module coders should also note that stacked extbans are not available if   DISABLE_STACKED_EXTBANS is defined. - Added extended ban ~R:<nick>, which only matches if <nick> is a registered   user (has identified to services). This is really only useful in ban   exemptions, like: +e ~R:Nick would allow Nick to go through all bans if he   has identified to NickServ. This is often safer than using +e n!u@h. - Added Extended Invex. This is very much like extended bans, in fact it   supports some of the same flags. Syntax: +I ~character:mask   Currently supported are: ~c (channel), ~r (realname) and ~R (registered).   This can be useful when setting a channel invite only (+i) and then   setting invite exceptions such as +I ~c:#chan (or even ~c:+#chan), while   still being able to ban users.   Because action modifiers (~q/~n/~j) make no sense here, extended invex   stacking (+I ~a:~b:c) makes no sense either, and is not supported.   Suggested by DanPMK (0002817), parts based on patch from ohnobinki.   Module coders: set EXTBOPT_INVEX in the ExtbanInfo struct used by   ExtbanAdd() to indicate that your extban may also be used in +I. - Invex (+I) now always checks cloaked hosts as well. Just like with bans,   it checks them also when the user is not currently cloaked (eg: did -x, or   is currently using some VHOST). - Fixed client desynch caused by (un)banning, reported by Sephiroth (#2837).

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2817	[unreal] ircd	feature	N/A	2006-02-13 11:56	2010-08-14 20:40
Reporter:	DanPMK	Platform:
Assigned To:	syzop	OS:	any
Priority:	normal	OS Version:	any
Status:	resolved	Product Version:	3.2.5
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	Request: Extended Invex
Description:	Exteneded bans is one of my favorite features with Unreal, yet it only works with +b and +e. Any chance this could be added to work with the +I Invite exceptions?
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0011231) Stealth    2006-02-13 23:14	This could be fun...
(0013138) Shining Phoenix    2007-01-28 03:06	Soo...is this going to be implemented?
(0013417) tabrisnet    2007-04-15 17:38	fun doesn't mean good.
(0014018) syzop    2007-05-07 12:38	I suppose it isn't a too bad idea? Like +i and +I ~c:#somechan, that's safer than +b *!*@* +e ~c.. just as an example. oh wait.. I already confirmed it ;)
(0014610) Shining Phoenix    2007-07-27 04:26	Like +i and +I ~c:#somechan, that's safer than +b *!*@* +e ~c.. just as an example. ------ That's a good idea, I like to minimise use of exceptions. And I would use +I ~c
(0014762) syzop    2007-09-06 13:02	I suppose this would be quite easy to implement, huh? /me looks at aquanight and wolfsage Would be nice to have at least 1 new interesting feature in 3.2.8, if not too hard.
(0016269) syzop    2010-08-14 20:39	Fixed in CVS .863: - Added Extended Invex. This is very much like extended bans, in fact it   supports some of the same flags. Syntax: +I ~character:mask   Currently supported are: ~c (channel), ~r (realname) and ~R (registered).   This can be useful when setting a channel invite only (+i) and then   setting invite exceptions such as +I ~c:#chan (or even ~c:+#chan), while   still being able to ban users.   Because action modifiers (~q/~n/~j) make no sense here, extended invex   stacking (+I ~a:~b:c) makes no sense either, and is not supported.   Suggested by DanPMK (0002817), parts based on patch from ohnobinki.   Module coders: set EXTBOPT_INVEX in the ExtbanInfo struct used by   ExtbanAdd() to indicate that your extban may also be used in +I. - Invex (+I) now always checks cloaked hosts as well. Just like with bans,   it checks them also when the user is not currently cloaked (eg: did -x, or   is currently using some VHOST).

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3942	[unreal] ircd	feature	have not tried	2010-08-05 22:05	2010-08-05 22:05
Reporter:	ohnobinki	Platform:
Assigned To:		OS:
Priority:	low	OS Version:
Status:	new	Product Version:	3.2.9
Product Build:		Resolution:	open
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	typechecking for module hooks
Description:	It would be nice to make it harder to mismatch hooks. For example, the compiler could detect that hooks are being mismatched if each hook is given a function prototype typedef or something. Or, maybe this could be as simple as a function like: HookAddExArg(Module*, int hooktype, int (*intfunc)(), int num_args); Assumably, if a hook changed its interface, the number of arguments passed to the hook would also change. Maybe this idea is completely pointless. Unrealircd could just choose to never change the signatures of hook functions. If a hook needed to be changed, it could be renamed to HOOKTYPE_BLAH_V2 or something.
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3932	[unreal] installing	minor	have not tried	2010-07-15 13:07	2010-08-04 03:38
Reporter:	syzop	Platform:
Assigned To:	ohnobinki	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	3.2.8
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	Update c-ares to latest version
Description:	...just like TRE 0003916, this has to be done before 3.2.9 release.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0016254) ohnobinki    2010-08-04 03:38	In CVS. - Upgraded c-ares to 1.7.3. API seems compatible with c-ares-1.6.0. (0003932)

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3939	[unreal] ircd	minor	always	2010-07-20 04:44	2010-08-04 02:04
Reporter:	warg	Platform:
Assigned To:	ohnobinki	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	3.2.9
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	patch to fix for various compiler warnings
Description:	patch fixes these warnings: # GCC 4.4.4 ssl.c: In function ‘ssl_get_cipher’: ssl.c:437: warning: assignment discards qualifiers from pointer target type # GCC 4.3.2 s_user.c: In function ‘check_for_target_limit’: s_user.c:463: warning: cast from pointer to integer of different size # GCC 4.3.2 support.c: In function ‘encode_ip’: support.c:1824: warning: cast to pointer from integer of different size
Steps To Reproduce:
Additional Information:
Attached Files:	warg-warn-fix.patch (1 KB) 2010-07-20 04:44 unreal-3939-fix-casts-const.patch (3 KB) 2010-07-22 19:29

Notes
(0016241) syzop    2010-07-22 12:19	I wonder if binki can spot the error in this patch ;)
(0016243) ohnobinki    2010-07-22 14:08	base64 encoding a pointer instead of an IP address? I'd have to look at the context to verify the last two chunks of the patch.
(0016245) syzop    2010-07-22 15:22    (edited on: 2010-07-22 15:23)	exactly.. in chunk 2 and 3 you now deal with the pointer itself, which would result in broken nickip and broken target flood detection. 3 obviously just not add the & I think. for 2.. if you look at the CURRENT code, it's pretty mysterious :P. Basically a pointer is set to the value of the ip (aka: to the IP itself), and then the pointer is b64encoded. Ok, that might work, but is rather... odd. presumably for 2 the & as in the patch should be done, and the & should be removed for the b64_encode in the line under it? Or maybe you could even do without using 'cp' in that part. I did not test... If you, binki, would like to take this, and test it, then feel free to commit for 3.2.9. (assuming you're not going to rewrite the whole function... but just those few lines :D)
(0016246) warg    2010-07-22 16:42	sorry for my mistake
(0016247) ohnobinki    2010-07-22 19:30	unreal-3939-fix-casts-const.patch: use double-casting to make GCC happier.
(0016249) syzop    2010-07-24 22:19	does this work on non-C99 compilers, binki? Like will it define those types if they don't exist... (see our coding guideline nr 9) also, like I said for 2.. I'd rather like: - cp = (u_char *)ia.s_addr; - b64_encode((char *)&cp, sizeof(struct in_addr), buf, 25); + b64_encode((char *)&ia.s_addr, sizeof(struct in_addr), buf, 25); assuming that fixes the warning for warg too... warg, could you test that? On a side note warg, looking at your warnings, they are 64 bit related I think [except for nr 1 of course] :). I can't test it, as I don't have a 64 bit system. If all from above is satisfied, then feel free to commit.
(0016250) ohnobinki    2010-07-25 03:04	> does this work on non-C99 compilers, binki? Like will it define those types if they don't exist... (see our coding guideline nr 9) The documentation for AC_TYPE_INTPTR_T claims that these types will be defined. Like you can't test the 64-bit-related problems, I can't test this ;-). I suppose that #define-ing this in win32's fixed setup.h would be the correct solution? And hopefully win32 means no 64-bit support...?
(0016251) syzop    2010-07-25 20:07	yea, think so :)
(0016253) ohnobinki    2010-08-04 02:04	- Fix a few compiler warnings with some double-casting and another const. (0003939) - Define intptr_t in win32's setup.h. (0003939) I didn't test much other than that the unrealircd runs, links in normally, and works with clients like I'd expect it to. I.e., I don't know what circumstances cause encode_ip() to be used or how to test the throttling code. Oh, and I can only hope that my #define in win32/setup.h works ;-).

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3934	[unreal] documentation	minor	have not tried	2010-07-15 13:10	2010-07-23 23:49
Reporter:	syzop	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:	3.2.8
Product Build:		Resolution:	open
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	Update translations
Description:	Once the docs are finalized, so when at RC1, I need to send the updates (diffs) to the translators. Preferably, restore the translators mailing list, as it's currently not functioning. Also, need to go through outdated translations -- preferably BEFORE rc1. Some have not been touched for like 2 or 3 years and should maybe be scheduled for removal?
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0016198) Bock    2010-07-15 13:49	Maybr not removal, mark as depricated and ask people via site what we want new translators :]
(0016199) syzop    2010-07-15 15:55    (edited on: 2010-07-15 16:10)	Yeah, and I should act on those abandoned docs now. I just posted a message on the forums, see http://forums.unrealircd.com/viewtopic.php?f=15&t=6611 [^] asking for Spanish and Greek translators EDIT: .. and Dutch, I don't like doing that myself ;p Last updates (excluding myself doing version changes): Spanish: Sat Dec 2 11:11:39 2006 UTC Greek: Sat Dec 2 09:56:07 2006 UTC Turkish: Fri Jul 13 23:02:47 2007 UTC French: Fri Dec 21 16:45:02 2007 UTC I think for French and Turkish I might still be able to prod them to get things up to date. I'll try that first before asking new people ;) Only the German, Russian and Hungarian translated docs are somewhat up to date (.. I'm not counting 6 months out of date).
(0016248) vonitsanet    2010-07-23 23:49	I can help a bit with the Greek language. :-)

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3192	[unreal] ircd	minor	always	2007-01-06 06:01	2010-07-22 14:36
Reporter:	Shining Phoenix	Platform:	i386
Assigned To:	ohnobinki	OS:	Linux
Priority:	normal	OS Version:	2.6.10-1.771_FC2
Status:	resolved	Product Version:	3.2.6
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	Add a new simple extban
Description:	Ban mode +b ~j:stuff would only stop matching users from joining, not nickchanging and speaking. It's corresponding exception (+e ~j:stuff) would only let matching users join, and not affect speaking and nickchanging. If I want to let someone join, but not speak or nickchange, this would do the job well :)
Steps To Reproduce:
Additional Information:
System Description	Unreal IRCd 3.2.7 3rd party modules:  m_uline - $Id: m_uline.c,v 1.13 2004/03/09 10:32:28 angrywolf Exp $ (Command /uline) [PERM] [3RD]  m_regexcept - v0.1 (ExtBan ~E) [PERM] [3RD]  m_hostforward - $Id: m_hostforward.c,v 1.0.2 2005/02/15 16:13:15 Special Exp $ (Forward users by hostmask to another channel) [PERM] [3RD]  courtroom_lite - $Id: courtroom_lite.c,v 1.4 2004/07/02 20:58:28 angrywolf Exp $ (Channel mode +U (courtrooms)) [PERM] [3RD]
Attached Files:	unreal-3192-m_extban_join.patch (5 KB) 2010-07-20 18:47 unreal-3192-extban-modej.patch (3 KB) 2010-07-22 01:04

Notes
(0013036) Sakkath    2007-01-09 07:52	Why not use ~q and ~n?
(0013037) Sakkath    2007-01-09 07:52	I mean honestly, why let a person in the channel if they have absolutely no rights? The other extbans I find are useful enough?
(0013052) Shining Phoenix    2007-01-14 02:51	There was some specific purpose for this, but now I've forgot it.
(0013053) Sakkath    2007-01-14 10:01	Lol.
(0013056) aquanight    2007-01-15 15:48	Well, +b ~j I can see useful: you want people of a specific hostmask have to be invited (for example, particularly annoying ISPs like AOL: you can +b ~j:*!*@*.aol.com, and they have to be /invited, but once allowed in, can speak/nickchange freely - you might give a few "known good" people access to /chanserv INVITE themselves), but anyone else can join fine. +e ~j just gets a "free ride" on account of the fact that +b/+e pretty much use the same system (yes I see nearly no use for that).
(0013057) syzop    2007-01-15 16:01	thanks for the example aquanight. without it, this had little chance :P
(0013060) Sakkath    2007-01-15 20:08	Most people would probably not even see that this function exists, but since so many of us use UnrealIRCd, now that you've posted an example, I guess some would find it useful. Thanks for the ex :-p. This might be best as a module too keep the core's "core" functionality and not have stuff some might find unnecessary :-p.
(0013076) Shining Phoenix    2007-01-21 22:39	I had a situation where I wanted to use it today :) This guy was cloning in a channel where I don't allow it, so I set a ban on him, a nickchange exception and a quiet exception. A single ~j ban would be nicer than a ban and two exceptions. Modifying the core to add this feature would be better than having someone make a module for it, which will crash the IRCd. /me stabs 3.2.6's handling of parametered channel modes from modules D:<
(0013079) syzop    2007-01-22 06:21	This can be perfectly fine implemented in a module. Of course, you're right, if you don't know C or are unable to create a good UnrealIRCd module, then it could crash. Just don't say it's not possible!
(0013110) aquanight    2007-01-25 11:27	Added (to core) in devel branch .2333 .
(0016189) syzop    2010-07-14 21:15	reopened for 3.2.9
(0016231) syzop    2010-07-20 20:48	Ehm.. regarding the patch. Yes, I understand you want it modulized, as it can be loaded if the user wants it. But, please just integrate it with the other extbans for now, there's no reason to make an exception to ~j when ~c/r/n and such are already in the core. Perhaps in 3.2.10 / 3.3 we can choose to modulize stuff some more, but for now just do it like the rest.
(0016232) ohnobinki    2010-07-20 21:03	> But, please just integrate it with the other extbans for now, there's no reason to make an exception to ~j when ~c/r/n and such are already in the core. OK, it just appeared from the thread above that it should be a module ;-).
(0016233) syzop    2010-07-20 21:19	ah, now I re-read it, I understand how it appeared that way ;)
(0016234) ohnobinki    2010-07-22 01:05	unreal-3192-extban-modej.patch: integrates into core using existing conventions.
(0016238) syzop    2010-07-22 11:47	Good :)
(0016244) ohnobinki    2010-07-22 14:36	In the original patch in help.conf, I refered to ~j as ~r and had grammar mistakes -- fixed before applying. - Add an extbasn of the schema +b ~j:*!*@* which _only_ prevents a user from joining a channel. (0003192) in CVS :-).

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3133	[unreal] documentation	minor	always	2006-12-02 10:49	2010-07-22 14:04
Reporter:	syzop	Platform:
Assigned To:	ohnobinki	OS:	ANY
Priority:	normal	OS Version:	ANY
Status:	resolved	Product Version:	3.2.6
Product Build:	RC1	Resolution:	fixed
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	Add SSL client cert documentation (oper, link blocks, etc)
Description:	Document that we allow the 'sslclientcert' password authentication everywhere (like in place of 'md5' etc), if SSL is enabled. It would be nice if this could be explicitly documented somewhere, maybe in the oper block (see 'additional information' field below). It's also extremely useful for server links, probably good idea to explicitly document it there as well. Of course any other suggestions or attempts as to how to put this in the docs are welcome as well. Actually, maybe we could make a section which explains all authentication methods supported (md5, crypt, sslclientcert, etc) and refer to that from each section. Currently it's a mess that we have to repeat the list 'valid blalba methods are: md5, crypt, ..' at like 5 places ;P. Still, I think a seperate "howto" section for oper certs and link blocks would be a good idea. It's a shame this nice feature is completely undocumented atm ;)
Steps To Reproduce:
Additional Information:	Bricker made a start on this (well, oper client certs), attached. Probably at least part of it can be (re)used :)
Attached Files:	UnrealSSLDocs.doc (96 KB) 2006-12-02 10:49

Notes
(0012801) Bricker    2006-12-06 19:13	So basically, instead of how I had it setup for just the operblock, you wan an entire section for using SSL Certs? I'll (write) another one, and see if anyone else doesnt wanna edit it, or add to it
(0013533) WolfSage    2007-04-18 16:24	*Punts Bricker* Well? ;)
(0013563) Bricker    2007-04-18 20:30	pft, sure i'll get on it over my weekend. ty again for reminding wolfsage
(0014345) stskeeps    2007-06-12 15:26	*Punts Bricker again*
(0014352) Bricker    2007-06-12 17:36	my bad guys, i just dont remember stuff that well anymore. kick me in the channel tonight and i'll get on it
(0016174) syzop    2010-07-14 17:29	I don't know about what exact text, but it would be nice to finally have some text about this in 3.2.9....
(0016236) ohnobinki    2010-07-22 01:22	- Remove browser compatibility listing from HTML docs. - Added information about ``oper::password::auth-type sslclientcert'' and the same for link::password-receive::auth-type. (0003133) - A little bit more of interlinking and using id="" instead of <a name="" /> I'm not sure if my changes are enough to resolve this bug.
(0016237) syzop    2010-07-22 11:45	Yup, looks sufficient :) (I only did some really minor edits, like moving 'crypt' up in your list, as to make it sorted from easiest to hardest to crack, and some caSE edits when I was at it)

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3941	[unreal] installing	trivial	always	2010-07-22 12:00	2010-07-22 13:57
Reporter:	ohnobinki	Platform:	amd64
Assigned To:	ohnobinki	OS:	Gentoo
Priority:	normal	OS Version:	2.0
Status:	assigned	Product Version:	3.2.8
Product Build:	CVS 2010.07.20	Resolution:	open
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	pkg-config support for curl
Description:	I get a false warning about libcurl not having c-ares enabled at compiletime. I pasted proof into Additional Information. I suspected that ./Config would make the same mistake, but in my quick test it didn't.
Steps To Reproduce:	1. Use Gentoo :-) 2. Install curl into the system with cares support enabled
Additional Information:	checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for TRE... yes checking for CARES... yes checking /usr/bin/curl-config... yes configure: WARNING: cURL is compiled without c-ares support. Your IRCd will possibly stall when REHASHing! checking curl_easy_init() in -lcurl... yes configure: creating ./config.status config.status: creating Makefile config.status: creating src/modules/Makefile config.status: creating unreal config.status: creating ircdcron/ircdchk config.status: creating include/setup.h config.status: include/setup.h is unchanged ohnobinki@ohnopublishing ~/unreal.0 $ echo :-O :-O ohnobinki@ohnopublishing ~/unreal.0 $ eix -e curl * dev-haskell/curl      Available versions: ~1.3.5 {doc profile}      Homepage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/curl [^]      Description: Haskell binding to libcurl [I] net-misc/curl      Available versions: 7.20.0-r2{tbz2} ~7.20.1 ~7.21.0 {ares gnutls idn ipv6 kerberos ldap libssh2 nss ssl test threads}      Installed versions: 7.20.0-r2{tbz2}(21:21:37 05/05/10)(ares gnutls ipv6 kerberos ldap lib32 ssl test -idn -libssh2 -nss)      Homepage: http://curl.haxx.se/ [^]      Description: A Client that groks URLs Found 2 matches. ohnobinki@ohnopublishing ~/unreal.0 $ echo 'I see my ares enabled up there...' I see my ares enabled up there... ohnobinki@ohnopublishing ~/unreal.0 $ readelf -d /usr/lib64/libcurl.so |grep libcares  0x0000000000000001 (NEEDED) Shared library: [libcares.so.2] ohnobinki@ohnopublishing ~/unreal.0 $ curl-config --configure | grep -o -e '.--enable-c\?-\?ares.' '--enable-ares' You may find interest in: ohnobinki@ohnopublishing ~/unreal.0 $ curl-config --libs -lcurl ohnobinki@ohnopublishing ~/unreal.0 $ curl-config --static-libs /usr/lib64/libcurl.a -Wl,--as-needed -Wl,-O1 -Wl,-t -Wl,--enable-new-dtags -Wl,--hash-style=both -lcares -lldap -lrt -L/usr/lib64 -Wl,-rpath -Wl,/usr/lib64 -O2 -pipe -march=athlon64 -combine -ftree-vectorize -falign-functions=16 -falign-labels=16 -falign-jumps=16 -g0 -Wno-system-headers -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lresolv -ldl -L/usr/lib64 -Wl,-rpath -Wl,/usr/lib64 -O2 -pipe -march=athlon64 -combine -ftree-vectorize -falign-functions=16 -falign-labels=16 -falign-jumps=16 -g0 -Wno-system-headers -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lresolv -ldl -lz -lgnutls Note that --static-libs's output may include libs required for dependencies of libcurl.a. That is, if libcurl uses another library that requires -lcares, curl-config --static-libs will list -lcares even if curl wasn't compiled with support for it.
Attached Files:	unreal-3941-pkg-config-libcurl-r1.patch (10 KB) 2010-07-22 13:56

Notes
(0016240) syzop    2010-07-22 12:07	> I expect the pkg-config support half of this is more controversial. Also, I can remove the hint to the user about forcing compilation against a libcurl that doesn't have cares if you want ;-). Yes, please remove.. we don't want to encourage users doing silly things :) Anyway --> 3.2.10
(0016242) ohnobinki    2010-07-22 13:57	unreal-3941-pkg-config-libcurl-r1.patch: removed message about avoiding libcares check :-p. Will be committed when the repo is open for 3.2.10.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3940	[unreal] installing	trivial	always	2010-07-20 16:03	2010-07-22 12:02
Reporter:	ohnobinki	Platform:	amd64
Assigned To:	ohnobinki	OS:	Gentoo
Priority:	normal	OS Version:	2.0
Status:	resolved	Product Version:	3.2.8
Product Build:	CVS 2010.07.20	Resolution:	fixed
Projection:	none
ETA:	none
3rd party modules:
QA:	Not touched yet by developer
U4: Need for upstream patch:	No need for upstream InspIRCd patch
U4: Upstream notification of bug:	Not decided
U4: Contributor working on this:	None
Summary:	./configure claims curl doesn't have cares enabled, could use pkg-config
Description:	I get a false warning about libcurl not having c-ares enabled at compiletime. I pasted proof into Additional Information. I suspected that ./Config would make the same mistake, but in my quick test it didn't.
Steps To Reproduce:	1. Use Gentoo :-) 2. Install curl into the system with cares support enabled
Additional Information:	checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for TRE... yes checking for CARES... yes checking /usr/bin/curl-config... yes configure: WARNING: cURL is compiled without c-ares support. Your IRCd will possibly stall when REHASHing! checking curl_easy_init() in -lcurl... yes configure: creating ./config.status config.status: creating Makefile config.status: creating src/modules/Makefile config.status: creating unreal config.status: creating ircdcron/ircdchk config.status: creating include/setup.h config.status: include/setup.h is unchanged ohnobinki@ohnopublishing ~/unreal.0 $ echo :-O :-O ohnobinki@ohnopublishing ~/unreal.0 $ eix -e curl * dev-haskell/curl      Available versions: ~1.3.5 {doc profile}      Homepage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/curl [^]      Description: Haskell binding to libcurl [I] net-misc/curl      Available versions: 7.20.0-r2{tbz2} ~7.20.1 ~7.21.0 {ares gnutls idn ipv6 kerberos ldap libssh2 nss ssl test threads}      Installed versions: 7.20.0-r2{tbz2}(21:21:37 05/05/10)(ares gnutls ipv6 kerberos ldap lib32 ssl test -idn -libssh2 -nss)      Homepage: http://curl.haxx.se/ [^]      Description: A Client that groks URLs Found 2 matches. ohnobinki@ohnopublishing ~/unreal.0 $ echo 'I see my ares enabled up there...' I see my ares enabled up there... ohnobinki@ohnopublishing ~/unreal.0 $ readelf -d /usr/lib64/libcurl.so |grep libcares  0x0000000000000001 (NEEDED) Shared library: [libcares.so.2] ohnobinki@ohnopublishing ~/unreal.0 $ curl-config --configure | grep -o -e '.--enable-c\?-\?ares.' '--enable-ares' You may find interest in: ohnobinki@ohnopublishing ~/unreal.0 $ curl-config --libs -lcurl ohnobinki@ohnopublishing ~/unreal.0 $ curl-config --static-libs /usr/lib64/libcurl.a -Wl,--as-needed -Wl,-O1 -Wl,-t -Wl,--enable-new-dtags -Wl,--hash-style=both -lcares -lldap -lrt -L/usr/lib64 -Wl,-rpath -Wl,/usr/lib64 -O2 -pipe -march=athlon64 -combine -ftree-vectorize -falign-functions=16 -falign-labels=16 -falign-jumps=16 -g0 -Wno-system-headers -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lresolv -ldl -L/usr/lib64 -Wl,-rpath -Wl,/usr/lib64 -O2 -pipe -march