Re: Is OpenSMTPD worthy of OpenBSD inclusion?

[Joel Rees]

2015/10/07 0:10 "Артур Истомин" :
>
> On Tue, Oct 06, 2015 at 02:20:31AM +0300, Kimmo Paasiala wrote:
> > On Mon, Oct 5, 2015 at 10:52 PM, Артур Истомин

wrote:
> > > On Mon, Oct 05, 2015 at 01:07:24PM -0400, STeve Andre' wrote:
> > >> The smtpd code is very good.
> > >
> > > static void
> > > filter_tx_io(struct io *io, int evt)
> > > {
> > > struct filter_session   *s = io->arg;
> > > size_t   len, n;
> > > char*data;
> > > charbuf[65535];
> > >
> > >
> > > switch (evt) {
> > > case IO_DATAIN:
> > > data = iobuf_data(>ibuf);
> > > len = iobuf_len(>ibuf);
> > > memmove(buf, data, len);
> > > buf[len] = 0;
> > >
> >
> > You just validated all the concerns about the quality of OpenSMTPd and
> > also the need for peer/code reviews. That is not production quality
> > code by any measure.
>
> I mean exactly that. It is sarcasm about "very good code".
>

Well, you know, if I'm supposed to judge an entire project based on a
supposedly unchecked pointer parameter, and a supposedly unchecked length
given to a block move (both occurring in a statically declared function)
I'd still want some sort of a pointer to the file it came from, and a
pointer to the bug report filed for it and any discussion on the mailing
lists that occured concerning the code in question.

Otherwise, I'm judging the reporter more severely than whoever wrote the
code.

Joel Rees

Computer memory is just fancy paper,
CPUs just fancy pens.
All is a stream of text
flowing from the past into the future.

Re: Is OpenSMTPD worthy of OpenBSD inclusion?

[lists]

By now the thread starter should already be well aware that the
correct thing would have been to ask for some comforting words the
report from the third party code audit was and is going to result in
further improvements.

And then thank the developers for sharing the audit details, the work
done so far and the immediate follow up and best effort to improve it
all for the rest who don't have the skill, time or courage to work on a
challenging project.

Instead he chose to bitch, whine and insult the buddies who try to
provide features in trade of more interest and exposure in real usage.
It's a call for eyeballs, how much simple can it get, just try to
contribute or be supportive, if you can't just shut up, Jason.

Sure the OpenSMTPD is worthy of inclusion as it is in base, otherwise
it would not be there. What kind of a nonsense question is this,
rephrasing the old Confucius saying "be a man about it" does nothing
but waste time and asks for a challenge response. Who needs this?

Only someone trying to interfere or cause turmoil, so retreat your
words or admit you tried causing damage and hope there is way to repair
it.

As nobody of interest in the internals of the featuritis involved, my
best hopes, and certainly the wide groups of users, are the OpenSMTPD
project makes it further and this is reassuring enough already.

Re: Is OpenSMTPD worthy of OpenBSD inclusion?

[Артур Истомин]

On Tue, Oct 06, 2015 at 02:20:31AM +0300, Kimmo Paasiala wrote:
> On Mon, Oct 5, 2015 at 10:52 PM, Артур Истомин  wrote:
> > On Mon, Oct 05, 2015 at 01:07:24PM -0400, STeve Andre' wrote:
> >> The smtpd code is very good.
> >
> > static void
> > filter_tx_io(struct io *io, int evt)
> > {
> > struct filter_session   *s = io->arg;
> > size_t   len, n;
> > char*data;
> > charbuf[65535];
> >
> >
> > switch (evt) {
> > case IO_DATAIN:
> > data = iobuf_data(>ibuf);
> > len = iobuf_len(>ibuf);
> > memmove(buf, data, len);
> > buf[len] = 0;
> >
> 
> You just validated all the concerns about the quality of OpenSMTPd and
> also the need for peer/code reviews. That is not production quality
> code by any measure.

I mean exactly that. It is sarcasm about "very good code".

Re: Is OpenSMTPD worthy of OpenBSD inclusion?

[Consus]

On 18:47 Mon 05 Oct , Jason A. Donenfeld wrote:
> 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.

Oh, so you were that guy who released "stable" ebuild without Berkeley
DB support? I vaguely remember I had to ask QA to fix it because you
ignored the bug report.

Re: Is OpenSMTPD worthy of OpenBSD inclusion?

[STeve Andre']

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"  
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

Re: Is OpenSMTPD worthy of OpenBSD inclusion?

[Gilles Chehade]

On Mon, Oct 05, 2015 at 06:47:18PM +0200, Jason A. Donenfeld wrote:
> Hi folks,
> 

Hi,

I initially didn't intend to answer but I feel insulted by your comments
and some facts need to be set straight.


> 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

The Qualys audit didn't just fall on us.

I was asked a long time ago if I'd be interested in an audit, to which
I answered positively because, I quote: if more eyeballs track bugs in
our code and spot them before bad guys do, the better for our project.

The audit was meant to catch bugs we let through before bad guys found
them and this is what happened. I would have prefered they didn't find
any bug but I'm happy they were found and fixed during an audit rather
than discovered by someone random in a long time from now.

Not to mention that these bugs were mitigated for the most part and as
far as I know, you only had to update code, not your system.


> discovered a remotely exploitable buffer overflow that was being
> triggered in the wild [2]. If you comb through the OpenSMTPD misc

You found a buffer overflow, we have left three lines of debug code by
accident, there is no debate or excuse over this, _we failed_.

I'll just clarify that it happens in a chrooted unprivileged process
allowing you to run arbitrary code (?) as user _smtpd in /var/empty.

I have provided a diff _immediately_ and published a release shortly
a few hours later after I had a chance to test on different systems,
and slip in other fixes just for the sake of not making a one-fix
release. I think it could have been handled worse.


> 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.

That is complete bullshit.

Whenever a security issue is spotted or reported, we always fix asap
and produce a bugfix release. People are credited and users are told
that a bugfix release is coming. We don't let security issues rot.

As for people reporting issues on the mailing list, no wonder, we do
publish all of our snapshots and ask people to report issues. And we
have done this for over a year, while a huge refactor was happening,
You should know, you complained on a few occasions that experimental
code tha was critical for you was not stable, and we told you to run
a stable version.

The mailing list is public and archived.

If there are so many buffer overflows, remote denials, and a host of
nasty glitches and security vulnerability, they will have no problem
seeing that I'm lying. For example when we do the pre-release test &
we call for people to report ANY bug affecting stable.


> 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.

Your point of view.

smtpd is still young, it will have bugs, we will have to improve.

i'll still run it in production because occasional updates beat having
to deal with anything i had to deal with in the past. ever.


> 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.
>

I call bullshit on this.

If we don't count mailing list posts, and I don't, you have made an
impressive amount of less than 10 contributions in the last 2 years
out of which over half were trivial diffs, then some are actually a
false positive because it's me mentionning you:

  $ git log|grep -i zx2c4|wc -l
1
  $ git log|grep -i donenfeld|wc -l
8

I appreciate all contributions, even one-liners, but to say that it
contributed in "significant" ways is beyond a stretch of the word.
Stay humble. please.

You did contribute a lot to the mailing-list, people can judge your
behaviour and tone there and determine by themselves how nice it is
to deal with someone assuming that developers work for him.

At the same time, they can browse our tracker to see how many times
you have requested 

Re: Is OpenSMTPD worthy of OpenBSD inclusion?

[Артур Истомин]

On Mon, Oct 05, 2015 at 01:07:24PM -0400, STeve Andre' wrote:
> The smtpd code is very good.  

static void
filter_tx_io(struct io *io, int evt)
{
struct filter_session   *s = io->arg;
size_t   len, n;
char*data;
charbuf[65535];


switch (evt) {
case IO_DATAIN:
data = iobuf_data(>ibuf);
len = iobuf_len(>ibuf);
memmove(buf, data, len);
buf[len] = 0;

> 
> 
> On October 5, 2015 12:47:18 PM EDT, "Jason A. Donenfeld"  
> 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

Re: Is OpenSMTPD worthy of OpenBSD inclusion?

[Ted Unangst]

Jason A. Donenfeld wrote:
> 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?

These questions all relate. I'm not very involved, but I can answer some of
them. As I'm sure you know (but some others may not) smtpd development has
been split into two branches for some time. This was to enable the development
of the filtering feature. This code was developed outside the main tree
precisely to allow it to mature.

Unfortunately, this had the unintended consequence of marking all the code in
openbsd as "deprecated". All of the openbsd developers were basically waiting
for the filter branch to land to avoid too much divergence. We are working to
make some adjustments in communications and attitude.

I don't think the smtpd developers are to blame for this situation, because
the rest of us allowed it to happen. Writing a mail server is a big project,
and many of us promised our support, but then that support didn't materialize
due to the above.

In short, things broke down, but we have a pretty good idea why, and know what
to do about it.

Re: Is OpenSMTPD worthy of OpenBSD inclusion?

[Kimmo Paasiala]

On Mon, Oct 5, 2015 at 10:52 PM, Артур Истомин  wrote:
> On Mon, Oct 05, 2015 at 01:07:24PM -0400, STeve Andre' wrote:
>> The smtpd code is very good.
>
> static void
> filter_tx_io(struct io *io, int evt)
> {
> struct filter_session   *s = io->arg;
> size_t   len, n;
> char*data;
> charbuf[65535];
>
>
> switch (evt) {
> case IO_DATAIN:
> data = iobuf_data(>ibuf);
> len = iobuf_len(>ibuf);
> memmove(buf, data, len);
> buf[len] = 0;
>

You just validated all the concerns about the quality of OpenSMTPd and
also the need for peer/code reviews. That is not production quality
code by any measure.

Is OpenSMTPD worthy of OpenBSD inclusion?

[Jason A. Donenfeld]

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