I personally would love to see the MySQL data moved out of the library and into a config file. The thought of recompiling vpopmail if/when my database info changes is disconcerting. Configuration data belongs in configuration files, not shared libraries. The only concern of course is that apps which link against libvpopmail need to know where to get the login info, so perhaps it needs to be made "automagical" that even a shared library call will open up the config, grab the info and then execute against the correct MySQL server. On Friday 18 July 2003 19:23, Tom Collins wrote: > On Friday, July 18, 2003, at 03:55 PM, Doug Clements wrote: > > It looks like there's 2 main problems he's detailing. The first he > > details looks pretty darn obviously a bug. Can anyone comment on why > > this buffer isn't cleared, and why it hasn't been fixed? > > If someone can give me better guidance, I will go in and fix the > problem on the vpopmail side. > > What functions does authdaemon make use of in libvpopmail? > > libvpopmail may need a major overhaul and review for memory leaks, > especially if it's like QmailAdmin. Since QmailAdmin runs as a CGI, no > one has been very careful about freeing allocated memory when it's done > being used. I'm not sure if similar coding practices are present in > vpopmail. > > > I'm not sure how to address the library problem. I've come across it, > > and anyone who halfway knows what they're doing should know how to get > > around it, but we all (sqwebmail and vpopmail lists) still get people > > who have problems with it. This sounds fixable by the patch I just saw > > that keeps the authentication information in a seperate file. Are > > there any objections to doint this and relaxing the restrictions on > > the lib directory (at least make it executable) and the actual > > library file (make it readable)? The hard-coded login information was > > the only valid reason I remember for having the lib permissions like > > that. Anyone? > > I liked that patch, and I want to integrate it into an upcoming release > (with review from others of course). I agree that the MySQL > information should live in a non-world-readable file owned by vpopmail, > perhaps stored in ~vpopmail/etc instead of /var/qmail/control. > > Does anyone see a reason it should be hardcoded into the lib? > > > I've never seen this problem really anaylzed and properly investigated > > on the vpopmail side. > > > > I really would like sqwebmail and vpopmail to work well together, it > > would be quite a shame to lose the interoperability over some bugs > > that should really be fixed regardless. > > I'm not intimately familiar with sqwebmail, but I'll commit to fixing > whatever is broken in vpopmail. Should I just examine authvchkpw.c to > see how it interfaces to vpopmail, and work on the parts of vpopmail > that it touches? Otherwise, it will probably be necessary to review > each function in vpopmail to make sure it could be called repeatedly, > work properly, and not leak memory. > > -- > Tom Collins > [EMAIL PROTECTED] > http://sniffter.com/ - info on the Sniffter hand-held Network Tester
-- Nicholas Harring System Administrator Webley Systems, Inc. Ph# 877-609-4795
