On Thu, Nov 10, 2011 at 8:35 AM, Graydon Hoare <[email protected]> wrote: > 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?
For comparison, the Go language has a crypto library, written in Go, as part of its standard library. (It's written by one of the few people I'd trust to get it right, but new crypto code is still scary.) For their v1 release they plan to kick it out into a submodule: https://docs.google.com/document/pub?id=1ny8uI-_BHrDCZv_zNBSthNKAMX_fR_0dc6epA6lztRE&pli=1 (search for "crypto"). Go's model is that it's trivial to install modules from third parties -- instead of 'import "crypto"' in your code you can write 'import "github.com/foobar/crypto"' and a built-in program "goinstall" knows how to extract those references from your source, download, compile, install, etc. So I think they don't worry too much about what is core or not. But Haskell's model is similar (though cabal takes a lot more effort to participate in) and my experience as an enthusiast is that it is kind of a disaster: any given project requires a bunch more additional modules, frequently in versions that conflict with the versions you already have installed. This may not be a problem in Go just due to the youth of the language and libraries (I haven't, for my bits of Go code, ever actually needed to use goinstall; their standard library is pretty large). My lurker's opinion on this subject in particular: as always in these discussions I wish you guys would aggressively limit scope by punting it for later, and just worry about how to not paint yourself into a corner for the future once all the other stuff (like "can I build hello world quickly") is in place. :) _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
