2 ms·

> Ring is mostly C/Assembly Crypto needs to be written in Assembly to ensure that operations take a constant time, regardless of input. Writing it in a high le

> Ring is mostly C/Assembly Crypto needs to be written in Assembly to ensure that operations take a constant time, regardless of input. Writing it in a high level language like C or Rust opens you up to the compiler "optimising" routines and making them no longer constant time. But you already knew this. And you also knew that the security audit (https://github.com/rustls/rustls/blob/master/audit/TLS-01-report.pdf https://github.com/rustls/rustls/blob/master/audit/TLS-01-re...) of ring was favourable > No issues were found with regards to the cryptographic engineering of rustls or its underlying ring library. A recommendation is provided in TLS-01-001 to optionally supplement the already solid cryptographic library with another cryptographic provider (EverCrypt) with an added benefit of formally verified cryptographic primitives. Overall, it is very clear that the developers of rustls have an extensive knowledge on how to correctly implement the TLS stack whilst avoiding the common pitfalls that surround the TLS ecosystem. This knowledge has translated reliably into an implementation of exceptional quality. As a bonus, rustls is under active development with sponsorship from Google, AWS and fly.io, with the aim of making a high quality, memory-safe TLS stack - https://www.memorysafety.org/initiative/rustls/ https://www.memorysafety.org/initiative/rustls/ You said > a standard library with feature flags and editions would make rust ridiculously much more productive What's the difference between opting into a library with a feature flag and opting in with a line in Cargo.toml? Let's say you want to use the de-facto regex library. Would it really be ridiculously productive if you said you wanted the "regex" feature flag instead of the "regex" crate? I do agree that the standard library does need a versioning story so they can remove long deprecated functions. Where it gets complicated is if a new method is reintroduced using the same name in a later edition.

rastignack 4y ago
> What's the difference between opting into a library with a feature flag and opting in with a line in Cargo.toml? Let's say you want to use the de-facto regex library. Would it really be ridiculously productive if you said you wanted the "regex" feature flag instead of the "regex" crate? If you are all alone developing and can audit the crate properly, sure. However when there’s a team, whose favorite lib should we pick ? How many of them shall we audit ? What’s their license ? How’s code attribution managed ? Etc etc
- nindalf 4y ago
  Rust had a small standard library and that’s ok (https://blog.nindalf.com/posts/rust-stdlib/ https://blog.nindalf.com/posts/rust-stdlib/) Your concerns are valid, but Rust has chosen a different set of trade offs. The link outlines the pros and cons.

rastignack 4y ago

> What's the difference between opting into a library with a feature flag and opting in with a line in Cargo.toml? Let's say you want to use the de-facto regex library. Would it really be ridiculously productive if you said you wanted the "regex" feature flag instead of the "regex" crate? If you are all alone developing and can audit the crate properly, sure. However when there’s a team, whose favorite lib should we pick ? How many of them shall we audit ? What’s their license ? How’s code attribution managed ? Etc etc

nindalf 4y ago
Rust had a small standard library and that’s ok (https://blog.nindalf.com/posts/rust-stdlib/ https://blog.nindalf.com/posts/rust-stdlib/) Your concerns are valid, but Rust has chosen a different set of trade offs. The link outlines the pros and cons.