On Sat, 29 Jun 2002 07:29:28 +0200 (CEST) Gerhard Häring <[EMAIL PROTECTED]> wrote:
GH> I found nothing. Is this page really all? GH> http://www.washington.edu/imap/c-client-list.html Yes. If you have any questions, you can post them to the c-client mailing list or maybe ask here first. There are also some (awfully out of date) docs in the c-client distribution which are also in doc/-client.doc in our cvs. GH> Where can I download it, etc.? ftp.washington.edu/pub GH> Are the developers the same that develop the UW IMAP server? ^ There is no 's'. The sole developer is Mark Crispin (MRC). GH> I'm asking because I personally found that their FAQ entry about GH> insecure C functions showed a higher level of cluelessness than I could GH> tolerate. It'd be a pity if c-client was of the same code "quality". I don't like c-client that much and its code is surely weird -- it is LISP translated to C and this shows. However I'd really think twice before accusing MRC of being clueless. He is anything else (stubborn, close minded if you want, sometimes arrogant, almost never what you'd call "nice"...) but not clueless. If you want my opinion, he is a really competent guy and this is not something I say often. [later] GH> > Could you share with us the details of problems with the code quality you GH> > have found so we can better understand the problems and perhaps learn some GH> > things? GH> GH> Well, I personally didn't find any problems myself, but there were security GH> problems with the IMAP server in the past: A long time in the past, though. GH> http://www.washington.edu/imap/buffer.html Quoting from the page above: There have been no root compromise vulnerabilities in imapd since 1998. GH> YMMV, but my opinion about GH> GH> With all this in mind, the software has been inspected, and it is believed GH> that all places where buffer overflows can happen have been fixed. The GH> strcpy()s that are still are in the code occur after a size check was done GH> in some other way. GH> GH> is that such a simple-minded security analysis only finds the obvious bugs Well, it should find most buffer overflows if done properly. Unfortunately, there are still some left and I work around them by double checking the buffers in our code when possible. On the bright side, there are almost no bugs in c-client which, considering what it does, is quite impressive. GH> The conclusion for Mahogany would IMO be to use wxString and/or the C++ GH> string class instead of char*, where possible. We do it, of course, but if there is a buffer overflow inside c-client we still can't do anything about it. GH> Am I seeing this right that c-client provides a standard interface for IMAP GH> and NNTP? Does mail_fetch_overview work with IMAP, too? Yes. c-client is OO: there is an abstract base class, i.e. the driver interface, and different implementations of it for each folder type. E.g. mail_foo() typically calls mbox_foo(), nntp_foo(), imap_foo(), ... Another important thing: you never call imap_foo() or nntp_foo() directly, but always use the mail_foo() functions. GH> The reason I'm asking all this is that I'm trying to speed up the fetching GH> of NNTP header info, which right now is intolerably slow. There was a reason mail_fetch_structure() was used in MailFolderCC.cpp. I think mail_fetch_overview() doesn't bring us some entries which we need but I don't remember which one(s) any longer. Of course, we might still use it for NNTP... GH> One more: what about adding an additional method to the Sequence class that GH> returns start/end pairs, something like GH> GH> struct StartEndPair { GH> UIdType start; GH> UIdType end; GH> } GH> GH> bool GetNextPair(UIdType n, size_t& cookie, StartEndPair& pair); GH> // returns false if end GH> // may also return tuples like (13, 13) GH> GH> It might also be enough to add a method that exposes m_seq. It could be that GH> this is enough for mail_fetch_overview, but I haven't checked, yet. This is what Sequence::GetString() is for: it returns the string in the format mail_fetch_overview() wants. Regards, VZ ------------------------------------------------------- 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
