On 05/17/2011 10:36 AM, Douglas Hubler wrote: > On Mon, May 16, 2011 at 7:55 PM, Joegen Baclor<[email protected]> wrote: >> On 05/13/2011 08:37 PM, Douglas Hubler wrote: >>> I think we need to decide as a project, if we want to be in the sip >>> parser business. If we do, then it sounds like all the things you >>> recommend and then some would need to be built. >> A crash/regression test is only required if we decide to enter into the SIP >> parser business? Seriously i do not get the wisdom behind this comment. > It probably would have been more clear if i wrote : *stay* in the sip > parser business. > > >>> If not, I would try >>> to fix any specific issues you run into complete with unit tests for >>> those fixes >> We already did and patched was accepted by you personally. > oh, ok, I thought you found other issues. > >> 1. Stay put and see if there are no more crash scenarios we have missed and >> simply correct them as we encounter them. This can be a nightmare scenario >> because in most cases, the bug is encountered not by QA but in actual client >> live install. > I reread your original post and you mention how in case #2 causes a > buffer overrun. Do we know that, that isn't was caused problem #1? > >
No we don't. It's one of the items I would like to prove or disprove via an actual crash test made specifically for it. >> 2. Review the transport layer thoroughly and see where we could put more >> safeguards agaist possible buffer overruns when tokenizing sip messages. >> >> 3. Modify the tokenizer functions to always have the string boundary known >> by its actual length so safeguards effectively becomes moot. > Your post highlights the deficiencies of the test suite, and the > amount of work needed to get this stack solid. I don't know the code > at all, so i can only reply with what I've heard through the years > about it. The sore spots of the sip stack has always been lack of > features and poor performance. I didn't hear a lot about crashes, > although I'm sure there were a few. Development moved very slowly, > TLS was in the works for literally 8 years and maybe still not > entirely there. Whatever the reason is for this, not many people > would dispute these facts. > Long term plan to keep a buggy or hard to maintain software is not a > plan I'd recommend. This is a totally different path but equally an option I would be willing to take. It won't happen overnight and a regression test that would take weeks if not several days is a small price to pay in exchange for the peace of mind that at least enough has been done to assure less surprises of similar nature we will be facing in the future. > I think it's really about 2 choices: put the time > into the one we got or patch it along until we can replace it. You > know the sip stack more than I at this point, so if you know it to be > worth the effort than maybe you (or anyone) highlight it's strengths > compared to other stacks so many of us can be a little more educated > on this subject. > I'd leave this for another discussion one day when we get 4.6 out. For now, my main concern is 4.6 and i want to at least give it a certain level of scrutiny as far as the parser is concerned. Remember that the bug is found in 4.0 and is proven to still persist up to current git-head. My original post is basically a press on the panic button that what if others like it is still there and we allow it to propagate to 4.6 simply because current regression test scope did not catch it "now". _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
