Ah, the classic buffer overflow problem.
Well, in M's case wxString is what is used. (That is not an absolute truth though, since I dont know all of the code. But I guess Vadim will fill in the details that are missing.) On Sat, 29 Jun 2002 13:12:49 +0200 (CEST) Gerhard H�ring <[EMAIL PROTECTED]> wrote: > Am Sat, 29 Jun 2002 11:10:10 +0200 (CEST) schrieben Sie: > > On Sat, 29 Jun 2002 07:29:28 +0200 (CEST) Gerhard H�ring wrote: > > > > > I found nothing. Is this page really all? > > > http://www.washington.edu/imap/c-client-list.html > > > > > > Where can I download it, etc.? > > > > > > Are the developers the same that develop the UW IMAP server? I'm > asking > > > because I personally found that their FAQ entry about insecure C > functions > > > showed a higher level of cluelessness than I could tolerate. It'd > be a > > > pity if c-client was of the same code "quality". > > > > Could you share with us the details of problems with the code quality > you > > have found so we can better understand the problems and perhaps learn > some > > things? > > Well, I personally didn't find any problems myself, but there were > security > problems with the IMAP server in the past: > > http://www.washington.edu/imap/buffer.html > > This is the FAQ entry I took for extreme cluelessness: > > http://www.washington.edu/imap/IMAP-FAQs/index.html#5.4 > > YMMV, but my opinion about > > With all this in mind, the software has been inspected, and it is > believed > that all places where buffer overflows can happen have been fixed. > The > strcpy()s that are still are in the code occur after a size check > was done > in some other way. > > is that such a simple-minded security analysis only finds the obvious > bugs, not > the subtle ones that get introduced by side effects. By simple bug, I > mean that > if you change module A, the bug appears in module A. So, you'd better > redo the > entire security analysis after each change. Or just use string functions > that > will eliminate these possible attacks in the first place. Or just use a > higher-level language which doesn't core-dump by default in the first > place. > > The conclusion for Mahogany would IMO be to use wxString and/or the C++ > string > class instead of char*, where possible. -- Thomas Finneid email: [EMAIL PROTECTED] ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek No, I will not fix your computer. http://thinkgeek.com/sf _______________________________________________ Mahogany-Developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mahogany-developers
