On Fri, Nov 25, 2011 at 10:31 PM, bcs <[email protected]> wrote: > On 11/22/2011 08:16 AM, Piotr Szturmaj wrote: > >> bcs wrote: >> > > How many people in the D community have the experience and know-how to >>> review the security of an implementation? If there are less than 2 or 3 >>> people who can do that, can we afford to include native kernels? We >>> can't have just one and if we have only two and one leaves for some >>> reason the code becomes un-maintainable for lack of a reviewer. *I* >>> wouldn't be comfortable with less than about 4-5. >>> >> >> I know Regan Heath who wrote some crypto code for Tango. Also, I suspect >> that D _will_ gain more (crypto) contributors, especially after joining >> GCC. >> > > "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". > > > Minimum number of contributors/reviewers requirement in open-source >> project is at least unfortunate in my opinion. Nevertheless, I respect >> your thoughts. But imagine what could happen if Walter waited for >> contributors instead of starting D project on his own? >> >> Please realize that we do not implement every possible crypto algorithm >> at once. We need to start with something like hashing, then add >> encryption and other cryptographic primitives. >> > > 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). > > Yes, I'm intentionally being paranoid here but this is security and > paranoia is part of the job description darn-it. >
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.
