On 09/11/2011 4:39 PM, Elly Jones wrote:
In principle, there should exist Rust crypto libraries.
I'd stop here to discuss a bit further, before getting too into crypto.
In principle we should have libraries for lots of stuff. At some point
we are going to need to start having a more-serious discussion about
organization of the library ecosystem; I think this is a reasonable
place to begin the conversation.
"Crypto libraries" can mean anything from:
- NaCL: hard-wired to a small, secure, ultra-modern algorithm set.
- Suite B like: modern standards, but multiple modes of use.
- Botan, openssl, Crypto++ etc.: mix and match every algorithm ever.
Somewhere along the line openPGP and X.509 interop comes into play as
well. It's a *big* landscape. I don't think it's sensible to talk about
which point to choose in this landscape "for crypto" without forming a
larger philosophy about libraries in general. Crypto is a subset of
concerns that will come up over and over.
Let's talk a bit more generally about how to handle the tension between
"include everything in the standard library" and "make installations
tractable and easy to manage". Discuss! Is the python distribution the
model to aim for (massive stdlib, "all batteries included") or is the
C++ model better? So far we've talked some, but not a lot, about
following the python-y path. If so, how do we develop that? One big repo
with lots of submodules? Lots of stuff detected by configury? Automatic
bindings generted by a tool? On-the-fly bindings using clang as a
dependency?
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
