View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003869 | unreal | ircd | public | 2009-10-13 20:06 | 2015-08-08 16:37 |
| Reporter | Lupo | Assigned To | syzop | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | unable to duplicate | ||
| Product Version | 3.2.8 | ||||
| Summary | 0003869: Use of Tabs problematic in Unrealircd.conf | ||||
| Description | Usage of tabs in the config file is problematic : - Usage of tabs in the cloak-key block will result in different cloak keys being generated over different servers - Usage of tabs in oper blocks will result in invalid O-lines | ||||
| Steps To Reproduce | Create an unrealircd.conf with tabs in either blocks. | ||||
| Attached Files | unrealircd.conf (1,086 bytes) | ||||
| 3rd party modules | |||||
|
|
Could you paste an example? (or link to it) Because the exact place of the tab is likely to be relevant... before variable names, between variable and value, really in the value, etc etc... |
|
|
lupo, I can't guess any combination of tabs to cause different key values to be created. Maybe there is a chance the problem is in different implementations of things like isspace() and isalphe() on freeBSD (IIRC) that could cause different interpretations of things like spaces. |
|
|
I must say, all my IRCD's are running on different operating systems. The main hub is on FreeBSD, while the leaf servers are on linux flavors. |
|
|
Only a-z,A-Z,0-9 are allowed in cloak keys; there seems to be characters not in that range in the attached .conf. |
|
|
FYI, I (and nearly everyone else I guess) use tabs heavily in the conf, and never heard of this problem before. Perhaps the odd characters in the cloak keys are related? I don't know. I know the cloaking algorithm doesn't care, though. As for O lines, that too sounds very strange. Not sure how to proceed from here... You have indeed confirmed that if you replace the tabs with spaces it solves the issue? So it's not related to the 'strange characters' (don't know if the o line contained them)? If it were the 'strange characters' I would consider file formats.. utf8.. iso... etc.. as a possible problem, but if that is not the problem... then.. hm :P |
|
|
I have since stripped my entire config with tabs and have replaced them with sets of spaces. I haven't experienced any problems since. I think the cloak-key problem was generated by a couple of nonvalid characters, in my config there was an à and a ?. Might have been caused by mashing the keyboard too insensively. When i got the cloak key issue i replaced the original ones with a set i autogenerated, and then its fine. As for the o-lines I got this issue in the beginning of my setup, while adding multiple IP's to the o-line. As a result opering up wasn't possible. stripping the tabs seemed to solve the issue. Sadly, i haven't saved any unreal configs from then. |
|
|
Well, I did a few tests but nothing indicates a tab problem. I also tested things like: password test<TAB>; and such (even though you should always quote passwords), and it worked just fine (with password 'test'). Also other blocks or combinations, nothing strange happened. Obviously, things like password "test<TAB>"; will make it so the password 'test' doesn't work (only the password test<TAB> works then), as expected. What ohnobinki said with regards to isspace/isalnum/etc is also not the problem, as we use our own functions. And you said you've the weird behavior on all OS's. Since pretty much everyone - including me - in all setups (simple or complex) use tabs, it makes it very unlikely for this to be the issue. I'm in particular referring to tabs & oper blocks here... almost everyone uses tabs. And multiple host/ip lines is not uncommon either. There was a problem in hostmasks, in particular in ipmasks, in the oper block in 3.2.7 but that was fixed in 3.2.8, so that can't be the issue either. Now, what is the issue then? I don't know. As said, maybe strange characters indeed, you mentioned a few. Hard to find out now without a .conf with this problem :). Or are you using NICK_GB2312 / NICK_GBK / NICK_GBK_JAP? Then things change a little, as that makes it use different isalnum/etc functions. I'm not sure that would cause the behavior you described, but if you use it, it sounds relevant with regards to this problem. You'd have to explicitly enable this in include/config.h, though, so it's not something you'd accidentally turn on :P If it's like this (default)... /* If you want to support chinese and/or japanese nicks */ #undef NICK_GB2312 #undef NICK_GBK #undef NICK_GBK_JAP ...then it's good :P |
|
|
unable to reproduce |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2009-10-13 20:06 | Lupo | New Issue | |
| 2009-10-13 21:14 | syzop | Note Added: 0015933 | |
| 2009-10-13 22:45 | Lupo | File Added: unrealircd.conf | |
| 2009-10-14 15:21 | ohnobinki | Note Added: 0015934 | |
| 2009-10-17 15:09 | Lupo | Note Added: 0015937 | |
| 2009-10-23 09:06 | Tset | Note Added: 0015938 | |
| 2009-10-23 18:28 | syzop | Note Added: 0015939 | |
| 2009-10-23 23:15 | Lupo | Note Added: 0015940 | |
| 2010-02-11 18:57 | syzop | Note Added: 0016017 | |
| 2015-08-08 16:36 | syzop | Note Added: 0018613 | |
| 2015-08-08 16:36 | syzop | Status | new => closed |
| 2015-08-08 16:37 | syzop | Assigned To | => syzop |
| 2015-08-08 16:37 | syzop | Resolution | open => unable to duplicate |
