On Sat, Mar 01, 2003 at 03:50:50PM +0000, Steve Mynott wrote: > I probably shouldn't respond to this sort of thing, since the original > email is essentially flamebait since MTA choice and code review is > religious warfare petrol.
Not at all. I couldn't care less what MTA you use, but if it hammers my bandwidth, and if it breaks at least 2 RFC SHOULDs, then I feel that it's probably a bit shit. If it causes the postmaster to find it easier to fuck up due to its lack of rcpt time verification, then that's also not good, as it reduces the overall reliability of the global email system (in a very similar vein as not accepting bounces). > But to throw my two matches on the fire :-> OK. > On Saturday, Mar 1, 2003, at 10:27 Europe/London, Lusercop wrote: > >So 2 comments and at least 12 unique unobvious undocumented constants. > I think comment counting is a rather crude metric of code "quality" and True, but we were talking about commenting specifically in the message I replied to. > a lot of the constants aren't that unobvious in context since most > people looking at MTA source are likely to know how many seconds there > are in an hour etc. I ignored those in my count. I'd be very interested if you can explain to the group the *precise* meaning of the following constants with reference to the algorithm that DJB is using. (datetime.c: line 24): 4 (datetime.c: line 27): 11017 (datetime.c: line 29): 5 (datetime.c: line 29): 146097 (datetime.c: line 33): 146096 (-1 % 146097 -- why -1?) (datetime.c: line 35): 25 (datetime.c: line 36): 1461 (146097/100 but why?) (datetime.c: line 39): 306 (datetime.c: line 45): 5 (datetime.c: line 48): 10 (datetime.c: line 49): 59 (datetime.c: line 49): 2 I await your explanation with great interest. There are three values that you should not need to comment in computer science, 0, 1 and \infty. Anything else should be commented. That function is utterly ridiculous. It took me and several other people a few hours of constant brainstorming to work out what was going on. > I am no C guru but I found it relatively easy to modify parts of So that makes it alright? I've modified parts of ezmlm, because it's broken in interesting ways. It took me an hour to find the right place that I needed to modify code, for a single line change. That is not well-documented code. > djbdns. It's very much old school C and comments aren't a priority for > DJB but I disagree that its particularly badly written code. Of I find it hard to read, hard to verify and hard to follow. I claim it's badly written as a result. > course he uses his own library functions because he thinks the standard > UNIX ones broken. Certainly there don't seem to be any buffer > overflows or format string holes there AFAIK. That's because NO ONE CAN POSSIBLY FOLLOW THE ****ING CODE! It's completely intractable from a security point of view, you'd have to spend all your time rewriting it and commenting it in order to have a hope in hell of conducting a security review on it. > >I'd also like to bring your attention to a quote by Tony Finch: > >| <fanf2> what kind of dickwit writes install scripts in C? > >| <fanf2> oh djb *sigh* > An apparent IRC log of a bitchy comment made by someone associated with > a rival program (exim) seems to me a cheap gibe. Tony has nothing to do with exim. He happens to use it in his job, and his job involves working quite closely with its author, but I quote Tony for his wide experience with C and software projects in general, better would be to say that he's a committer in FreeBSD, and that he is a member of the ASF. > I have used and like both programs. I use and like exim. I use and detest qmail. > The main strength of qmail is probably its security model more than > ease of modification of code and so it appeals to sysadmins. Its security model is mostly DJBfud. The interactions between the qmail* users are, IME, not well understood, and you just kind of run DJB's installer and hope. Its queueing strategy is FIFO, which means that after an outage, it performs appallingly badly. It doesn't multiplex connections or messages, and therefore hammers remote servers bandwidth. > The main strength of exim is probably extendibility (which is why > programmers tend to like it) and certainly not security. Would you like to back that up with something other than FUD. What you haven't pointed out is that the configurations are not likely ones, and that actually there has been very little wrong with exim in many years of production system. > Example if you are running certain recent versions of exim and some > configurations you can mail to pipes to execute remote commands on the > exim mail server. Yes, as I point out above, those configurations are not default, or likely by anyone who's actually setting up a domain. > If you find anything like this in qmail DJB will send you $500. No, DJB would say "that's your own fault for configuring it like that, there are no holes in qmail, you can't have the $500". Are you really so naive as to think anything else? Have you seen DJB's reaction to being asked for useful features such as Recipient verification: "that's not in my reading of the spec so it's not needed in qmail". No matter that it makes the double-bounces fewer and therefore the mail system more reliable. One of the current enhancements being proposed to DNS is being vehemently opposed by DJB, because he doesn't want to change djbdns, and the proposal would work in every other nameserver, but isn't doable because of the completely idiosyncratic way that he writes his data structures. I'm glad that as a sysadmin you're able to audit the security of your own programs, and I'm really looking forward to your comprehensive security review of the qmail source code and its security. (or are you just relying on FUD from DJB and others about qmail?) -- Lusercop.net - LARTing Lusers everywhere since 2002
