Re: [MaraDNS list] Multiple issues in JsStrOS.c
Sam Trenholme <[email protected]> Sat, 2 Jun 2012 18:28:23 -0400
| Newsgroups | gmane.network.dns.maradns.general |
|---|---|
| Message-ID | <CAJxgfkQLJizRV_oD=HD9-Ptq-9OSd8fz4ExEQKbT7bGD-6EO-w@mail.gmail.com> |
Since this is attempting to come off as a security report, I will briefly humor Rich and reply to him even though it's not after the 20th. This is the only reply I'm going to give Rich unless he either: 1) Has found a CVE-worthy security report (he hasn't) 2) Has patches to submit to me and the mailing list. Keep in mind that attachments get scrubbed; Cc me when submitting patches. I will look at such patches after the 20th of this month. The bottom line, Rich, is that it is better to light a candle than cure the darkness. If you have an issue with MaraDNS' library, you would be a far more productive person if you submitted a patch to address the issue instead of just complaining on the mailing list. I'm sorry the libraries do not meet your arbitrary criteria of what a "good library" has, but you're not paying me enough to have me fix them for you. You are aware that MaraDNS 1 is no longer supported and that MaraDNS 2 only uses the really old code you're complaining about in the authoritative code, which means that nothing about MaraDNS 2's memory state can be changed by a remote attacker. Deadwood is a complete rewrite, and you haven't reported any issues with Deadwood's libs. MaraDNS 1 is only supported for serious security issues at this point, and to be honest, I'm currently deciding whether to cut off that support in 2015 or 2017. Probably 2015. "continues to functional normally when malloc() fails" has never been a design criteria for either MaraDNS or Deadwood. The only OSes I support are Windows and RHEL6-derived versions of Linux. Both OSes are either rebooting or randomly killing processes long before malloc() starts failing. Again, Rich, don't waste my time with random whining. I have finished MaraDNS; if you don't like the way it's written, submit a patch. This is my last out of band reply to you. I'm not going to reply to you until after the 20th of any given month, and only reply to you once a month, unless you have a CVE number. - Sam