You obviously never lived through the sendmail era. The smtpd code is very good. Bugs happen, and how the creators of a program react to them is what matters. The qualsys results were promptly dealt with.
I don't think there is much to discuss other than diffs that further the project. STeve Andre' On October 5, 2015 12:47:18 PM EDT, "Jason A. Donenfeld" <ja...@zx2c4.com> wrote: >Hi folks, > >Like many others, when I learned that OpenBSD was creating from >scratch an SMTP daemon, I was thrilled. The OpenBSD name has for a >long time been connected with security, stability, and reliability. I >was excited to see an extremely easy to configure yet powerful SMTP >daemon coming from such a venerable project as OpenBSD. Overtime, >OpenSMTPD has replaced all other mail daemons for me, and I've been >pleased to use another OpenBSD project as part of my critical >infrastructure. Code from OpenBSD is code that the community has >learned to trust, a reputation matched by few other projects. > >It has been, therefore, to my extreme dismay to discover in recent >months the sheer number of critical security vulnerabilities - in some >cases, remotely exploitable - in OpenSMTPD. Just this past week, >Qualys has reported an impressive audit result [1], with a scary >remote code execution vulnerability among others, and last night I >discovered a remotely exploitable buffer overflow that was being >triggered in the wild [2]. If you comb through the OpenSMTPD misc >mailing list, you'll find scattered reports of other similar bugs -- >buffer overflows, remote denial of service vectors, and a host of >other nasty glitches and security vulnerabilities -- and if you look >at the CVS repository or git repository, you'll see other such goodies >baked in there; most of them haven't been publicly revealed as >security vulnerabilities and were not assigned CVEs, which is an >irreverent point for most reasonably skilled malicious actors. > >The fact is, OpenSMTPD has suffered a disproportionately high number >of security issues, especially for a daemon as important as it. It is >not living up to OpenBSD's reputation, and it threatens the >OpenBSD.org frontpage security claim. I do not any longer believe >OpenSMTPD to be software that is trustable for use in critical >infrastructure at this point in time. > >Personally, I am very attached to OpenSMTPD. I have contributed to its >development in, what I think to be, significant ways, and I maintain >both distribution packages for it (Gentoo), as well as my entire >infrastructure, which is based on OpenSMTPD. I've "bet the farm" on >the project, so to speak. > >But I think it's time we take a step back and reassess the situation. >There are some critical questions that need to be answered. What >accounts for the high proportion of security vulnerabilities in a >project renowned for its brilliant developers and stringent review >processes? Do the OpenSMTPD developers have time -- and have they >displayed a presence of necessary free time -- to keep the project >healthy and moving toward stability at an acceptable pace? Have the >correct standards of releases been applied to the OpenSMTPD release >process? > >And most importantly: should OpenSMTPD continue to be a part of the >core OpenBSD project? Or should it rather spend some time maturing and >securing commitments from developers for maintaining it in a >consistent manner, before being accepted by such a reputable >organization as OpenBSD? > >Finally, if OpenSMTPD does continue to exist as a part of core >OpenBSD, I would strongly recommend some effort is organized to bring >top quality code reviewers and auditors to the source code, in order >to give the project the eyeballs it deserves. It would be a great >boost in confidence for many who use - or hoped to someday use - >OpenSMTPD to see that intelligent minds, capable of securing large >codebases, have put their efforts into making it secure. > >I hope this can begin some discussion on the best way forward toward >making OpenSMTPD a piece of infrastructure we can trust. My best >wishes for the project. > >Regards, >Jason > > >[1] http://seclists.org/oss-sec/2015/q4/17 >[2] http://seclists.org/oss-sec/2015/q4/25
