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.
