"we can't expect Gilles to be able to do it all alone"
Just like with GPG. In FOSS circles, there's all kinds of people that want to take the code but few to create it. So, people gripe about the state it's in while putting no effort in to improve it. At least the author contributes significantly. However, gotta wonder how many users it has vs how many are contributing code/audit.
Bet the difference has an impact on the situation. It's why I spend time here and there investigating proprietary, open-source models that require money or contributions to use the software. Doesn't even have be a lot: at least enough for a significant product to support at least one developer. That way the users are always investing into it and esp bug fixes happen.
gilles operates in a community where problems like this are taken very seriously, and where enough developer resources exist to sweep the smtp code base several times over.
I expect a lot of fixes coming up over the next few weeks.
The real problem is that the OpenBSD community didn't realise the state of things internally, because gilles and eric were trusted to not fuck up. This happens, since not everybody has time to follow every corner of the tree all the time. But when focus on a particular area is needed we can do it.
It's good that Jason pointed out these problems, however the manner in which this was done creates huge public exposure which puts pressure on all of us (especially gilles and eric) to produce results very quickly while we prefer moving slowly and being careful because that produces better results in the long term.
To be clear, I wasn't smearing any developers or the project relative to others. Just noting a common problem in OSS development that probably hurts their project to some degree.
Appreciate you adding detail on the project's situation. Also on how you all view the post and its effects. As HN gets exposure, do you a specific, alternative approach for anyone reading that might end up Jason's shoes to get the OpenBSD team focused on a particular project and digging into it? I'm guessing he didn't make an attempt outside the public disclosure or made an ineffective one.
Find out who's been involved with the area of the code base recently, and mail all their @openbsd.org addresses directly in one mail.
If they don't reply after a few attempts, or give unsatisfactory answers, try mailing Theo. He acts as arbitrator in such situations.
If even that doesn't help, your last option is to write good fixes yourself, and keep submitting them as diffs to tech@ until you're either banned from posting to the list (at which point you should just give up) or your diffs end up being commited.
That's crystal clear: now anyone reading knows the best approach. Makes sense, too. Except that last part.
I agree it's the best option to rollup the sleeves and just fix the problem you're griping about. However, a write-up like Jason's is a valid option, too, if person doesn't have time/resources/skill for that option. Because, at that point, known issues would've been ignored by everyone up to Theo despite it being in default install and under OpenBSD's quality image. A write-up drawing attention to the issue would be justified to prevent users from placing unjustified trust in that component. Being informed lets them take action either on improving the component themselves, limiting damage it could do, or just avoiding it altogether.
Still agree that the gripe should go to the developers and Theo first.
But Jason did send diffs, and we are discussing his situation as an example.
Anyway, like it or not, in the OpenBSD community, working diffs, especially ones that fix a security issue, are the best way of winning an argument. You can try to blog about it but you probably won't be taken as seriously. So if you really care to convince the community from the outside and everything else has failed, and you can't code C youself, find a friend who can and ask for help.
"we can't expect Gilles to be able to do it all alone"
Just like with GPG. In FOSS circles, there's all kinds of people that want to take the code but few to create it. So, people gripe about the state it's in while putting no effort in to improve it. At least the author contributes significantly. However, gotta wonder how many users it has vs how many are contributing code/audit.
Bet the difference has an impact on the situation. It's why I spend time here and there investigating proprietary, open-source models that require money or contributions to use the software. Doesn't even have be a lot: at least enough for a significant product to support at least one developer. That way the users are always investing into it and esp bug fixes happen.