Slashdot Mirror

Apparently freedesktop.org has devolved from a desktop standards initiative to a home of pointless wheel-reinvention. Here's a list of the projects listed above, followed by their existing, more mature counterparts:

Init Replacements: simpleinit, minit, jinit, runit, daemontools, serel. Progeny also has their own system based on Gooch's need/provide architecture.

D-BUS: CORBA

HAL: Discover

Bob, with all due respect, have even read Dan's short explanation of Software User's Rights? You have the right to modify Dan Bernstein's software as you see fit. If you don't want to use a particular feature, don't. If you want to install qmail into the /etc directory, go right ahead. If you want to use /daemons instead of /service you are free to do so.

What you don't have permission to do is distribute changed versions of Dan's software without his express permission. You can distribute a patch that makes the software act differently or install differently, but you can't modify the software and then distribute the modified version.

Personally, I'm extremely thankful I have DJBDNS, QMAIL, etc. because they make my life easier, not harder like you seem to imply.

Pray for the peace of Jerusalem!

Although this article refers to embedded systems, the earlier Booting Linux Faster article contained an overlooked post by TornSheetMetal, who had a great idea on how to make Linux, or any operating system start up faster on any system.

Simply run every startup script simultaneously, but have each script block until its dependencies have started. Nothing waits longer than it needs to, and there is no need for additional complex systems to check and manage dependencies.

This is VERY easy to do with daemontools and svok (both written by D.J. Bernstein, the author of qmail). Switch over and you'll never go back.

Although this article refers to embedded systems, the earlier Booting Linux Faster article contained an overlooked post by TornSheetMetal, who had a great idea on how to make Linux, or any operating system start up faster on any system.

Simply run every startup script simultaneously, but have each script block until its dependencies have started. Nothing waits longer than it needs to, and there is no need for additional complex systems to check and manage dependencies.

This is VERY easy to do with daemontools and svok (both written by D.J. Bernstein, the author of qmail). Switch over and you'll never go back.

even if you had the .COM zone, i believe you'd need a system capable of handling a process of something like 2-4GB in memory - 64bit, and a customized bind most likely.

It's not so much that DJB and the CDB file format is so tiny and efficient (though it is) as it is that BIND and BIND zones are huge and bloated.

You are joking right! Who is going to run this system? The government (US?). Microsoft? A new org like ICANN!!!!!

The reason the internet works is because it is open. Closing it off will just destroy it...

Perhaps a better idea would be to use a system like Internet Mail 2000 proposed by DJB

This systems reverses email by storing the message on the senders mail server, and a notification is sent to the receiver. A sender will not be able to hide by spoofing, since the message needs to be stored on their server. It would be much easier to block SPAM with a system like this, plus it would reduce bandwith requirements.

It's probably not perfect either, but it would be beter that regulating email...

Somewhat OT but djb has made similar claims for qmail and some of his other programs, and qmail is actually quite popular.

Why I am not surprised to hear someone proposing to add more breakage to BIND? I mean, it's already got a shit security model, a shit security record, a horse's ass of a data replication system, and a bunch of head-up-ass developers...

Thank goodness real DNS software exists.

And yes, I know you were being facetious. My points still stand. And mods -- since this is a discussion on DNS, don't mod me "offtopic" simply because you're BIND fanboys.

Sweet. As expected, you bring us around to the dirty little secret of your guranteed-secure qmail...

time passes...

The fact is that qmail has been a dead project for years now... all the stuff that has to be added to make the software at all useful as a real mailserver has to be done using third-party code. End result: djb's much touted security guarantee is totally meaningless in any practical sense.

Nothing is 100% secure

Oh really?

Nothing is 100% secure

Oh really?

I suggest that BIND (the software that runs 60% of the DNS) should be enhanced in several ways: The most important one, IMHO, is to [blah]

I have a better suggestion. The most important BIND enhancement is: to give a damn about security. No, wait, how about: to stop obfuscating the simple concept of Internet naming, leading everyone to believe that the DNS is somehow difficult to comprehend. Or: to abandom the demonstrably-stupid AXFR protocol. Or: ad nauseum.

Actually, all things considered, perhaps the most important BIND enhancement would be to disappear, and for everyone to start using real DNS software.

Speaking of tinydns: Notes on *.com wildcards .

The first thing I do when I install a Linux distro is wipe out sendmail. Running it is simply asking to be broken into. It is old, full of holes, and far past its prime. Why people still run it, I do not know...but it's probably for the same reason they still run BIND.

The alternatives I prefer to these veritable blocks of swiss cheese are qmail and djbdns (tinydns)

The first thing I do when I install a Linux distro is wipe out sendmail. Running it is simply asking to be broken into. It is old, full of holes, and far past its prime. Why people still run it, I do not know...but it's probably for the same reason they still run BIND.

The alternatives I prefer to these veritable blocks of swiss cheese are qmail and djbdns (tinydns)

That's why you should be using qmail, ya' code monkeys!

Great idea! I'll just download a package from my favorite distribution that's tuned qmail to mesh nicely with how my system is configured.

Hmm, they don't supply packages for qmail. Why not? They're not allowed to. If I take the time to make up such a package, I'm not allowed to give it to my friend.

Quoth Bernstein:

But that's a decision for the Apache maintainers, not the UNIX integrators!

Darn those pesky integrators, attempting to make their system internally consistent and trying to please their users!

I've heard great things about qmail, it's great that is available with source for no cost. But it's proprietary software, putting me at the mercy of Bernstein. If you want someone else to maintain a fork with features you desire, you're out of luck. It's fine if you're willing to accept that, but it's not acceptable to everyone. Fortunately there are other options available.

That's why you should be using qmail, ya' code monkeys!

Great idea! I'll just download a package from my favorite distribution that's tuned qmail to mesh nicely with how my system is configured.

Hmm, they don't supply packages for qmail. Why not? They're not allowed to. If I take the time to make up such a package, I'm not allowed to give it to my friend.

Quoth Bernstein:

But that's a decision for the Apache maintainers, not the UNIX integrators!

Darn those pesky integrators, attempting to make their system internally consistent and trying to please their users!

I've heard great things about qmail, it's great that is available with source for no cost. But it's proprietary software, putting me at the mercy of Bernstein. If you want someone else to maintain a fork with features you desire, you're out of luck. It's fine if you're willing to accept that, but it's not acceptable to everyone. Fortunately there are other options available.

Sendmail has remote exploits every couple of months at best. Why is anyone suprised any more? It's not as if it's easy to set up, administrate or is horribly high performance. It's about as middle of the road as you get. As many have pointed out before I'm sure, this is exactly why we complain about software from microsoft (and I mean just the software, not it's licences nor the biz tactics associated with it).

So why not look for alternatives, all you sysadmins out here? I for one prefer qmail. There are plenty of others.

I know it's hard to switch to a new system when you've gotten profficent in configuring something well, especially when you are so busy using it that you don't have time to play with something new to see if can work for your setup. But I can't see that running a frequently exploited mail server will cause anything but more work.

Who cares? Sendmail is obsolete.

qmail
postfix
exim

That's why you should be using qmail, ya' code monkeys! Seems like this happens every couple months.

everybody, click after me Do not attempt to own us

Doesn't work for me...then again, I've already fixed djbdns here to return NXDOMAIN when a lookup resolves to Verisign's squatter page. (A copy of the patch is here (the patch isn't mine, but the only place I've seen it is buried in bugs.gentoo.org) and an ebuild for your local Portage tree is here. To use the ebuild, you'll also need to copy Manifest and files/1.05-errno.patch from /usr/portage/net-dns/djbdns.)

Internet Software Consortium (ISC) is a not-for-profit corporation dedicated to developing and maintaining production quality Open Source reference implementations of core Internet protocols. ISC efforts are supported primarily by the donations of generous sponsors.

I think they need to reread the DNS' RFC's. I don't recall something along the lines of "to stop someone breaking the protocol spec, you aren't required to follow the spec yourself"

Btw, shouldn't ISC focus on fixing some bugs in BIND instead? Maybe they should check out djbdns...

• TinyDNS
• Power DNS
• NSD

If only Dan would write a secure shell package.

I noticed that the root servers serve out the IP directly. Somebody should write a filtering DNS cache program that detects if the gtld-servers.net servers respond directly. They are INTENDED to simply point you to the owner name server, not actually answer back with A records themselves.

In other words, detect if *.gtld-servers.net returns with anything other than an NS record, don't accept it.

I wonder how hard it would be to patch djb's dnscache software, which I use, to do that.

Professional TCP/IP and DNS

A quick hack for DJBDNS's dnscache to refuse to comply:


# diff -c query.c.bak query.c
*** query.c.bak 2003-09-15 22:55:38.000000000 -0700
--- query.c 2003-09-15 23:57:36.000000000 -0700
***************
*** 643,648 ****
--- 643,650 ----
pos = dns_packet_copy(buf,len,pos,header,10); if (!pos) goto DIE;
if (byte_equal(header + 8,2,"\0\4")) {
pos = dns_packet_copy(buf,len,pos,header,4); if (!pos) goto DIE;
+ /* Bad return value includes 64.94.110.11 */
+ if (byte_equal(header,4,"\100\136\156\13")) goto SERVFAIL;
save_data(header,4);
log_rr(whichserver,t1,DNS_T_A,header,4,ttl);
}



A better program might preload a list of addresses from a file.

I wonder how long it will be before there are patches for BIND/dnscache/etc...

Someone's already asked WRT BIND. I would be more interested in a fix for djbdns, though.

They happen because A) most code is written in C or C++, and B) everyone makes mistakes (even the finest open source developers overlook simple buffer overflows).

That's not true. qmail and djbdns do not have security holes. They were written using secure coding techniques that make them immune to things like buffer overflows. You can't "overlook" a buffer overflow with stralloc.

They happen because A) most code is written in C or C++, and B) everyone makes mistakes (even the finest open source developers overlook simple buffer overflows).

That's not true. qmail and djbdns do not have security holes. They were written using secure coding techniques that make them immune to things like buffer overflows. You can't "overlook" a buffer overflow with stralloc.

They happen because A) most code is written in C or C++, and B) everyone makes mistakes (even the finest open source developers overlook simple buffer overflows).

That's not true. qmail and djbdns do not have security holes. They were written using secure coding techniques that make them immune to things like buffer overflows. You can't "overlook" a buffer overflow with stralloc.

As far as I can tell, the press release you referenced wasn't mentioned in the original Slashdot postings. It's not fair to criticize someone for not reading something they didn't know existed, is it? In any case, while I'm sure the Deja Vu software is useful, it doesn't help those of us who aren't setting up clusters--there's still a need for reliable hardware. Check out http://cr.yp.to/hardware/ecc.html for reasons why.

Good point. A djbdns user myself, I'm not sure how BIND handles wildcards, but presumably the independent roots would have to get behind this for it to work 100%. It wouldn't necessarily matter if they didn't have *all* the roots, but one could argue that the roots should all return the same answer for a given query.

tinydnsA VERY secure DNS server to replace BIND.

The Ultimate Guide to FreeBSD This book includes information about how to set up Jails in FreeBSD.

tinydnsA VERY secure DNS server to replace BIND.

The Ultimate Guide to FreeBSD This book includes information about how to set up Jails in FreeBSD.

I have been using Courier for over two years now. No remote roots ever or problems of any kind (I am amazed!). It's open sourced and a full package (esmtp, pop, imap, webmail and a thousand other things). It gets my vote.

I used it for a couple months because I wanted to have Maildir type mailboxes and wanted an IMAP server, it would crash all the time and give me all kind of troubles. I then switched to Binc IMAP (Binc is not courrier), which claim to be better than Courrier, but it was actually worse. It wouldn't last one week without crashing and send a lot of junk in syslog. I finally settled for dovecot with qmail. I have been running it for 6 months now without any problem.

If we are to go through all the trouble of rolling out a new protocol, why would we roll one out that only kinda fixes the problem?

The IM2000 protocol fixes the problem at its source. Isn't that the kind of solution we should be looking for?

-Tom

As I recall djb had an alternative to SMTP called Internet mail 2000. The interesting thing about that was that the e-mail wasn't stored on the ISP's spool, but the senders spool until requested by the person whom the message was delivered to. It's an interesting concept. I think the combination of AMTP and internet mail 2000 would a good idea. The biggest advantage of this 2 pronged attack would be that the amount of cost shifting that occurs with spam would be greatly reduced and identification of the spammer is easier.

AMTP is a good idea but like any good idea there are a few caveats -

1. SMTP is simple and requires little overhead - that is gone with the X.509 certs and TLS

2. One may setup a web-server or mail-server at a moments notice to deal with traffic or get a project finished pronto. With AMTP that machine will have to get an x.509 cert to be able to send mail (and have it accepted) - thus increasing the amount of time and money that it takes to get these services in place. (Site wide certs would sacrifice the ablity to truly identify an offending machine)

3. There is nothing to stop a spammer from getting thousands of certificates and burning through them as they spam. Many spammers already right off dial up accounts, DSL, T1s and other form of access on an almost daily basis. This will simply be a another small expense that must be endured to send out an advertisement to "21 million confirmed opt in customers".

4. This won't stop spammers from hijacking others valid certs, such as on webservers running formmail.pl or mail servers that allow relaying or proxying through them.

The saddest part of this proposal is that eventually the "altruistic" protocol SMTP will die. Don't get me wrong, SMTP has a lot of flaws, but if you think of it in a more philisophical sense, it's a little sad. The Internet was based on the free exchange of ideas - and more importantly traffic. The spammers have forced us to censor ourselves, reduce or try to eliminate anonomity and move away from the "I trust you" model to the "your bad unless I can prove otherwise" model. The death of an egalitarian idea, that anyone could send e-mail. One more victim of spammers.

In the end if you want to stop UCE you will have to take the costs of such a business out of the cyber world and put them into the real world. This is a step in that direction.

cluge

As I recall djb had an alternative to SMTP called Internet mail 2000. The interesting thing about that was that the e-mail wasn't stored on the ISP's spool, but the senders spool until requested by the person whom the message was delivered to. It's an interesting concept. I think the combination of AMTP and internet mail 2000 would a good idea. The biggest advantage of this 2 pronged attack would be that the amount of cost shifting that occurs with spam would be greatly reduced and identification of the spammer is easier.

AMTP is a good idea but like any good idea there are a few caveats -

1. SMTP is simple and requires little overhead - that is gone with the X.509 certs and TLS

2. One may setup a web-server or mail-server at a moments notice to deal with traffic or get a project finished pronto. With AMTP that machine will have to get an x.509 cert to be able to send mail (and have it accepted) - thus increasing the amount of time and money that it takes to get these services in place. (Site wide certs would sacrifice the ablity to truly identify an offending machine)

3. There is nothing to stop a spammer from getting thousands of certificates and burning through them as they spam. Many spammers already right off dial up accounts, DSL, T1s and other form of access on an almost daily basis. This will simply be a another small expense that must be endured to send out an advertisement to "21 million confirmed opt in customers".

4. This won't stop spammers from hijacking others valid certs, such as on webservers running formmail.pl or mail servers that allow relaying or proxying through them.

The saddest part of this proposal is that eventually the "altruistic" protocol SMTP will die. Don't get me wrong, SMTP has a lot of flaws, but if you think of it in a more philisophical sense, it's a little sad. The Internet was based on the free exchange of ideas - and more importantly traffic. The spammers have forced us to censor ourselves, reduce or try to eliminate anonomity and move away from the "I trust you" model to the "your bad unless I can prove otherwise" model. The death of an egalitarian idea, that anyone could send e-mail. One more victim of spammers.

In the end if you want to stop UCE you will have to take the costs of such a business out of the cyber world and put them into the real world. This is a step in that direction.

cluge

This draft fails to provide any significant advance over SMTP. The use of TLS and authentication between MTAs merely provides a mechanism to identify policy violators. It does not (as the draft recognises) prevent fraud against a CA, it does not address the problem of distributing certificate revocations, it opens the door to a new era of DoS attacks against CA services (which will likely be far less robust than the DNS system), increases the barrier to entry for the ISP market (with costs being passed on to consumers, of course), and the opportunity for politically based service interrupts (like we already see with SPAM black lists) is just plain scary.

Further to the last point: ISPs are generally forced to react to SPAM rather than be proactive (it is generally impossible for an ISP to distinguish between UBE and opt-in lists). This means that spammers will always be one step ahead, and any network with enough bullying power can summarily demand the revocation of another ISP's certificate for policy violations. An entirely new class of disputes will arise, making SPAM black listing arguments seem tame.

The additional responsibilities this draft places on end users is also unacceptable. You will have to remember to flag your message "commercial" or "personal" and whether the distribution is "individual" or "customer". And of course is someone complains about the classification you could end up having your service terminates, so that the ISP can prove it took appropriate action against the "abuse".

We have to accept that it is a fact that we cannot get away from SPAM. The postal and Internet mail systems rely on the opportunity to send a message to any recipient. Implementing a client side PKI-based whitelist for mail would be trivial (and many people do this), but destructive to the communication medium. The object is not to get away from SPAM, but to ensure that we, as recipients, do not bear the cost of SPAM.

Any system that filters messages at your mailbox, or your ISP's server, costs you money. Your bandwidth and your ISP's bandwidth are wasted. AMTP may reduce this, but adds other hidden costs like a certified key and probably the ongoing maintenance of good relations with many peer MTAs to avoid accusations of abuse.

Anyone interested in alternatives to the SMTP system should take a look at D. J. Bernstein's Internet Mail 2000 ideas; in brief, the sender holds the message in his/her mailbox and make his/her bandwidth available to allow the mail to be downloaded by the recipient (who can obviously choose not to download it).

No, the only solution is Internet Mail 2000.

Sure, sendmail has had holes found in it from time to time. But we should remember that it has been a very *long* time,

Was March that long ago? Here's a historic list of holes and Dan Bernstein's list from 1993 to 1997.

And I have never yet met anyone whose system has been compromised as a result of these holes.

I have. It was last summer. I helped install a new system (Slackware running qmail).

We also shouldn't forget that whenever bugs have been found, they have been fixed immediately (if not before).

Definitely good to see however I still prefer the approaches taken by OpenBSD and qmail. That is: Build it right in the first place.

I prefer GNU/Linux distributions to the BSDs... I find the userland to be a lot more friendly and modern. But I absolutely loathe the fact that every time I do a default install of nearly any Linux distribution, I have to spend lots of time either (a) downloading security patches; or (b) disabling extra software I don't need.

For one thing, whomever believes it's a good idea to continue relying on sendmail and BIND deserves broken bones. There are secure, faster alternatives available, and while they're whining about backwards compatibility and the fac that DJB doesn't want them butchering his software, their users are getting rooted.

We also need to remember the distinction of what Linux really is. I'm not RMS, but we do have to remember that Linux is simply a kernel. It has indeed had security problems (the most recent that comes to mind is the ptrace exploit), and sometimes this is unescapable. But when I hit up for instance the slackware security advisory list, I notice that while there are a handful of system problems, they are also listing problems with software that has little to do with running the Linux system (BitchX, EPIC4, etc).

And then I remember that each time I go to Windows Update, I'm slammed with a list of critical security updates, some of which are even rollout packages containing many other security updates. And the volume of security updates on Windows Update still far surpasses that of my favorite distro.

Handing your average computer user your average linux distribution's default installation is like handing a baby a bunch of knives... the system usually works damn well and quite stable from the get-go, so they install it in a dark corner and forget about it.

Sorry. Other people managed to find djb's redo.
-russ

Right off the top of my head are these long-standing open-source packages with long histories of security holes: wu-ftpd [...] sendmail [...] vixie-cron

Wow, how could you forget the most obvious one?

The three you mentioned are indeed bad, but BIND is definitely, by far, the most bug-ridden, insecure, shoddily-designed piece of trash ever to embarrass the open-source community. No bitchfest about bad software is complete without mentioning BIND.

Between vixie-cron and BIND, I'd support a law prohibiting Paul Vixie from ever touching a computer again. Kinda like Kevin Mitnick's probation, but with actual justification this time around...

Anyway, a big "thank you" goes out to DJB for freeing the world from the mess that is BIND (and Sendmail, for that matter)!

According to http://cr.yp.to/surveys/sendmail.html and http://cr.yp.to/surveys/smtpsoftware6.txt, Sendmail has long been trending towards less and less hosts running it. As of his last survey two years ago, it was at 42%. And if you look only at "serious" MTAs, those for sites that have heavy mail volumes, you'll probably see even less Sendmail.

According to http://cr.yp.to/surveys/sendmail.html and http://cr.yp.to/surveys/smtpsoftware6.txt, Sendmail has long been trending towards less and less hosts running it. As of his last survey two years ago, it was at 42%. And if you look only at "serious" MTAs, those for sites that have heavy mail volumes, you'll probably see even less Sendmail.

I have been using Courier [courier-mta.org] for over two years now. No remote roots ever or problems of any kind (I am amazed!). It's open sourced and a full package (esmtp, pop, imap, webmail and a thousand other things). It gets my vote.

I used it for a couple months because I wanted to have Maildir type mailboxes and wanted an IMAP server, it would crash all the time and give me all kind of troubles. I then switched to Binc IMAP (Binc is not courrier), which claim to be better than Courrier, but it was actually worse. It wouldn't last one week without crashing and send a lot of junk in syslog. I finally settled for dovecot with qmail. I have been running it for 6 months now without any problem.

Qmail has a guarantee

But have you noticed the qualifiers? Sendmail works around bugs in the OS (and most of the CERT warnings involving sendmail are because of OS related issues and other delivery programs, not the sendmail core).

How many of the race conditions fixed in sendmail and apache exist today in qmail? Does qmail work around any linux kernal problems?

Of course, no discussion of DNSSEC would be complete without Bernstein's comments. And here are the slides from his talk in pdf.

Not being an expert on the topic, I find DNSSEC a little worrying, as it seems to be a consolidation of the centralized power of Verisign or whatever. Ideally we should be planning how to move away from traditional DNS altogether, as the single-rooted namespace has led to much political abuse. But that is a really hard problem to solve.

Of course, no discussion of DNSSEC would be complete without Bernstein's comments. And here are the slides from his talk in pdf.

Not being an expert on the topic, I find DNSSEC a little worrying, as it seems to be a consolidation of the centralized power of Verisign or whatever. Ideally we should be planning how to move away from traditional DNS altogether, as the single-rooted namespace has led to much political abuse. But that is a really hard problem to solve.