What are you talking about? ucspi is only needed if you want axfr. Both dnscache and tinydns do not require either ucspi or daemontools (although both are way better and more convenient/easier to use than inetd and init). If you don't like your services supervised with daemontools, then try runit, minit, and a hoopla of others. They're great timesavers, and make your systems more available.
The right thing to do is to run two services one for DNS cache, the other as your authoritative nameserver. Even BIND idiots recommend to run BIND this way.
> No, you need his gay ass daemontools shit. Not to mention you can't secondary or have someone else secondary your dns zones for you unless you set it up using scp copies. How fucking lame is that?
Liar, axfrdns service does it, and daemontools is far easier and more convenient to use than init scripts. Typical anti-DJB troll. Yum.
Not surprising, as BIND is as shown again and again a poorly designed and coded product. The fact that authors of this crap can't come up quickly with a working patch is laughable.
> We'll see what admins decide about who is right. In the meantime, if I really am a troll "abusing" the option of being labeled an Anonymous Coward, you certainly have been a most obliging sucker. Of course, that's not much of a change from being a most stalwart useful idiot for djb. Cheers!
No. it's just I enjoy feeding anti-DJB trolls such as yourself. Funny how they run out of baseless arguments in the end and fall flat on their face. Cheers!
> Sure... like I said before: to djb it's not a flaw, it's a feature! And, you know what? That's his business, and well in keeping with his rep as the archetype of the uber-opinated developer.
And not only to DJB. The rlimit() has been present in OSes for a while, unlike you, some people understand the trade-offs between simplicity and efficacy of something like rlimit(), and the error-prone and complex approach that Postfix takes to micro-manage memory allocation.
> If you patch it at all (and you have to if you want any of the innovations that have come about since the half a decade or so that qmail stopped development), the guarantee is no guarantee.
And who's claiming otherwise than the trolls such as yourself? This is obvious to anyone who's read it.
> Oh, and by the way, admin, if you think that qmail takes steps to protect you from known problems with the OSes it claims to support (as, according to dmelomed, other MTAs do), guess again.
Obviously if you have a serious OS problem that needs to be fixed, no MTA will be able to protect you no matter how hard it tries, and the resulting code would be bloat at best; the DJBs security guarantees are clear about this, you can't blame qmail for OS problems, and you can't blame qmail for problems in the patches - nobody is trying to hide this fact, only idiots that abuse AC for trolling on slashdot make believe otherwise.
You hypocrits use commercial software with closed source all the time, and don't complain about it either (Netscape's web browser back in 4.x days for instance). Additionally, many of the libraries used in DJBware are public domain.
DJB uses slashpackage that isn't familiar to most, but solves the packaging problem with a flare that is an eyesore in many Unix OSes. slashpackage isn't a requirement though, and you can back out of it before you compile.
The "exploits" reported are idiotic attempts to blackmail DJBware as evident from the mailing lists, author's responses, and people who know the software well and don't jump on the blackmail bandwagon. No one has claimed the security guarantee money yet.
It's also important to note for the anti-DJB idiot trolls that qmail's resource limits control is DOCUMENTED and recommended - rlimit() in either your shell or a utility such as softlimit.
Again, C can be much safer with good libraries AND practices. Java isn't THE answer to all our problems. qmail and djbdns are written in C for instance, and do not have a single buffer overflow.
I think any language zealotry is counter-productive and just counter-innovative, whether it's Java or Lisp.
And yes Virginia, Java can scale just as well or better than C for some tasks, see SEDA for instance. Not such a terrible surprise for those that know Apache still isn't such a great performer any way you look at it.
But there are libraries that are better than the standard C library, which is piss poor. People just settle for the standard C library instead, and suffer in the long run.
The memory allocation "vulnerability" isn't a vulnerability at all. As documented by the author qmail-smtpd's memory limits are best handled by the operating system, not the error-prone and complex data-structure limits Postfix et al. Venema some day failed to add the limit, and systems were probably vulnerable where qmail systems weren't since the limits are set with rlimit() in the shell or through tools such as DJB's softlimit AS DOCUMENTATION recommends.
Slashdot Mirror
What are you talking about? ucspi is only needed if you want axfr. Both dnscache and tinydns do not require either ucspi or daemontools (although both are way better and more convenient/easier to use than inetd and init). If you don't like your services supervised with daemontools, then try runit, minit, and a hoopla of others. They're great timesavers, and make your systems more available.
> make, make install, done.
Rooted. Done.
The right thing to do is to run two services one for DNS cache, the other as your authoritative nameserver. Even BIND idiots recommend to run BIND this way.
Wrong. Better init, not inetd.
> No, you need his gay ass daemontools shit. Not to mention you can't secondary or have someone else secondary your dns zones for you unless you set it up using scp copies. How fucking lame is that?
Liar, axfrdns service does it, and daemontools is far easier and more convenient to use than init scripts. Typical anti-DJB troll. Yum.
I can't wait to feed.
Not surprising, as BIND is as shown again and again a poorly designed and coded product. The fact that authors of this crap can't come up quickly with a working patch is laughable.
> We'll see what admins decide about who is right. In the meantime, if I really am a troll "abusing" the option of being labeled an Anonymous Coward, you certainly have been a most obliging sucker. Of course, that's not much of a change from being a most stalwart useful idiot for djb. Cheers!
No. it's just I enjoy feeding anti-DJB trolls such as yourself. Funny how they run out of baseless arguments in the end and fall flat on their face. Cheers!
> Sure... like I said before: to djb it's not a flaw, it's a feature! And, you know what? That's his business, and well in keeping with his rep as the archetype of the uber-opinated developer.
And not only to DJB. The rlimit() has been present in OSes for a while, unlike you, some people understand the trade-offs between simplicity and efficacy of something like rlimit(), and the error-prone and complex approach that Postfix takes to micro-manage memory allocation.
> If you patch it at all (and you have to if you want any of the innovations that have come about since the half a decade or so that qmail stopped development), the guarantee is no guarantee.
And who's claiming otherwise than the trolls such as yourself? This is obvious to anyone who's read it.
> Oh, and by the way, admin, if you think that qmail takes steps to protect you from known problems with the OSes it claims to support (as, according to dmelomed, other MTAs do), guess again.
Obviously if you have a serious OS problem that needs to be fixed, no MTA will be able to protect you no matter how hard it tries, and the resulting code would be bloat at best; the DJBs security guarantees are clear about this, you can't blame qmail for OS problems, and you can't blame qmail for problems in the patches - nobody is trying to hide this fact, only idiots that abuse AC for trolling on slashdot make believe otherwise.
No, we should expect them to use good methodologies, and good libraries.
Chuck Moore's 25x MISC stack machine technology.
See www.colorforth.com, and www.ultratechnology.com for more information on this overlooked, and underrated stuff.
You hypocrits use commercial software with closed source all the time, and don't complain about it either (Netscape's web browser back in 4.x days for instance). Additionally, many of the libraries used in DJBware are public domain.
DJB uses slashpackage that isn't familiar to most, but solves the packaging problem with a flare that is an eyesore in many Unix OSes. slashpackage isn't a requirement though, and you can back out of it before you compile.
The "exploits" reported are idiotic attempts to blackmail DJBware as evident from the mailing lists, author's responses, and people who know the software well and don't jump on the blackmail bandwagon. No one has claimed the security guarantee money yet.
It's also important to note for the anti-DJB idiot trolls that qmail's resource limits control is DOCUMENTED and recommended - rlimit() in either your shell or a utility such as softlimit.
Again, C can be much safer with good libraries AND practices. Java isn't THE answer to all our problems. qmail and djbdns are written in C for instance, and do not have a single buffer overflow.
Java can be scalable. See http://www.eecs.harvard.edu/~mdw/proj/seda/">SE DA
I think any language zealotry is counter-productive and just counter-innovative, whether it's Java or Lisp.
And yes Virginia, Java can scale just as well or better than C for some tasks, see SEDA for instance. Not such a terrible surprise for those that know Apache still isn't such a great performer any way you look at it.
Using ulimit in your shell, or another rlimit() tool before running the JVM would have prevented your trouble.
But there are libraries that are better than the standard C library, which is piss poor. People just settle for the standard C library instead, and suffer in the long run.
Java Java Java Java Java. Blah Java. Language zealotry bad.
Propolice is stack smashing protection for C, and OpenBSD for instance already ships compiled with protection by default.
These libraries already exist. The standard C library is crap, but not many people realize this.
The memory allocation "vulnerability" isn't a vulnerability at all. As documented by the author qmail-smtpd's memory limits are best handled by the operating system, not the error-prone and complex data-structure limits Postfix et al. Venema some day failed to add the limit, and systems were probably vulnerable where qmail systems weren't since the limits are set with rlimit() in the shell or through tools such as DJB's softlimit AS DOCUMENTATION recommends.
Troll.
And how much more time will it take to find holes in his software given its size and time on the market?
What's the likelyhood?
Idiot. smtpd_auth is not written by DJB.
Idiot. vchkpw is not written by DJB.
In other words, you are a troll.
> Picking a library for C is a good step, but using a safe language will take you farther and also make it less of a chore!
Depends on a task at hand.
There are nice string libraries to avoid buffer overruns in C, it's just people decide to stay wit standard C library due to lack of awareness.