On Fri, Nov 25, 2011 at 10:31 PM, bcs <span dir="ltr"><<a href="mailto:bcs@example.com">bcs@example.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 11/22/2011 08:16 AM, Piotr Szturmaj wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
bcs wrote:<br>
</blockquote>
<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

How many people in the D community have the experience and know-how to<br>
review the security of an implementation? If there are less than 2 or 3<br>
people who can do that, can we afford to include native kernels? We<br>
can't have just one and if we have only two and one leaves for some<br>
reason the code becomes un-maintainable for lack of a reviewer. *I*<br>
wouldn't be comfortable with less than about 4-5.<br>
</blockquote>
<br>
I know Regan Heath who wrote some crypto code for Tango. Also, I suspect<br>
that D _will_ gain more (crypto) contributors, especially after joining<br>
GCC.<br>
</blockquote>
<br></div>
"Wrote some crypto code" is a rather weak recommendation. Depending on how you interpret it, that would recommend *me*. A better recommendation would be "Mr Y gets paid by security company X to do crypto analysis" or "Mrs Z has published several well review papers on vulnerabilities in this kind of code".<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Minimum number of contributors/reviewers requirement in open-source<br>
project is at least unfortunate in my opinion. Nevertheless, I respect<br>
your thoughts. But imagine what could happen if Walter waited for<br>
contributors instead of starting D project on his own?<br>
<br>
Please realize that we do not implement every possible crypto algorithm<br>
at once. We need to start with something like hashing, then add<br>
encryption and other cryptographic primitives.<br>
</blockquote>
<br></div>
I have no problem with that comment. My concern revolves around the point that the implementation of cryptographic primitives has security implications. I'm worried that we don't have the resources to demonstrate that our implementation is at least as good as the currently available implementation. I'd rather Phobos not include a given primitive than contain one of unknown quality. What I'd like to see is that the crypto package quickly contain interfaces for all the primitives we can find pre-vetted Boost licensed implementations for. At that point I would have no issue with as methodical and meticulous effort to divest ourselves of external dependencies as we can get access to the expertises needed to vet our own implementations (to the same level as the code they are replacing).<br>

<br>
Yes, I'm intentionally being paranoid here but this is security and paranoia is part of the job description darn-it.<br>
</blockquote></div><br><div>How about putting a disclaimer on the module warning the code hasn't been through a rigorous security audit and point them at well established C libraries if they need that sort of assurance.</div>