Open richsalz opened 3 years ago
Interesting suggestion. Curious what others think.
I definitely would like clear distinctions for things like ring
(lots of C + assembly) vs rsa
(only rust) vs seqoia
(lot of rust, but crypto in C through bindings)
I think there's three layers which inherit from dependencies: rust, rust+asm, rust+FFI.
@jcape : do you think it's worth calling out all three? I was proposing "pure rust" and everything else.
Looking over the list, it might be easier to just call out the ones that use C/ASM, and maybe whether it’s optional
Otherwise it seems like 90%+ of the list would have “pure Rust” badges
@richsalz I feel like we're trying to measure "trustworthiness" or "safety" without dictating how it's measured, so it's really about feeding other folks' determinations of safety.
For me, I place the highest trust in rust+(audited) assembly, because I don't have to worry about what the underlying library is in FFI, and I don't need to worry about LLVM mis-optimizing something in a way that creates oracles or whatever.
sorry, hit the wrong button.
I am mostly concerned about being able to make trade-offs between, say, features and attack surface. To pick an easy example, rusttls doesn't have everything that openssl does, but maybe I'd prefer one or the other because of the underlying C code (in this case, from ring).
I'd definitely like to see this, especially in a Rust crypto context, since it's a differentiating factor of libraries like dryoc
in #56 from other libraries that provide only bindings to underlying libraries like sodiumoxide
does for libsodium
, or lean heavily on platform-specific code like ring
.
Is it worth having a badge for those items that are pure rust, as opposed to wrappers?