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 something and how many times we worked on it. It
sure seems ungrateful in retrospect given that on some of them, you
are bitching that we don't go fast enough.
> 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?
>
That will be the only thing we agree upon.
We had to do a huge refactor to add filters and we knew in advance
it would span over several releases, breaking smtpd for OpenBSD.
We decided to take this development to a private repository and we
made a public mirror as people were asking for snapshots to test.
You should know, you *really* wanted filters right ?
This resulted in two branches, making it twice as hard for us to
work correctly and preventing other OpenBSD developers from taking
a look at our changes.
This is not how OpenBSD works and this is not how we want to work.
We're currently discussing how to come back home, micro-diff by
micro-diff. the filters code is trickier to split and we have a
bit of work to make it reviewable. the easy way would be to not
support it, but you'd prefer that we keep it right ?
This is how we want to work. With other OpenBSD hackers.
> 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?
>
You have some nerve.
"securing commitments from developers for maintaining it" ?
You weren't complaining much about our commitments when we were working
on your feature requests and you were talking to us like we were your
employees using big words. Care to remind me who was commiting to work
on that masquerade or senders map feature that was so critical to your
infrastructure ? Who actually ping-ed you to let you know that the long
awaited feature was going to be part of a snapshot ?
You did complain alright, the project wasn't moving fast enough.
But that was before you complained it was moving to fast.
> 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.
>
We agree again.
The more eyeballs, the better.
Except that when we get help from external eyeballs you're unhappy.
Or is there another reason ?
> 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.
>
I'd be happy to believe you, and people may, but you're not sincere.
People may think you sent this mail out of nowhere but you did right
after I told you something unpleasant. Just a coincidence, right ?
While you were telling eric that you liked our work and that you had
respect for it, you drafted this, sent it and linked on so many site
that people started telling me in private that a psycho had a grudge
against us.
At least be honest about your motives.
You told me once that you were a "security expert" and that we could
sit around a beer so you'd tell me what's wrong in our design. If it
is true that you want the project to succeed and if you really are a
security expert then the project would have surely made a better use
of a design analysis report than this mail.
--
Gilles Chehade
https://www.poolp.org @poolpOrg
