RustCrypto
1.0 releases
This is a tracking ticket for 1.0 releases of all of the crates in this repository, except for signature which is already 1.0 (see RustCrypto/traits#237).
The main blocker for 1.0 releases of crates in this repository has been a desire to stabilize them after Rust ships stable const generics. There is now hope this may happen soon enough to warrant putting together a 1.0 stabilization plan:
https://without.boats/blog/shipping-const-generics/
That said, many of the crates maintained by this org have relatively fancy usages of type-level arithmetic using GenericArray which probably won't be available on stable Rust for a much longer period of time.
My best guess is we'll be trying to ship 1.0 versions some time in 2021. In the meantime, this is a place to track upstream Rust progress and make a plan for both replacing existing usage of GenericArray with const generics as well as shipping 1.0 versions of these crates which use a const generic API.
Note that const generics MVP is not sufficient, even if we forget about the fancy type-level arithmetic used in some crates. It even mentioned in the blog post:
This will mean, for example, that use cases like cryptographic hash traits which allow each implementation to specify a different length for the hash they output will still be out of scope for the MVP. This is a shame, but this feature will come eventually.
IIUC the main blocker here is rust-lang/rust#68436.
Also ideally I would like to release 0.* versions dependent on const generics first and release 1.0 only if no big changes will be needed in half to one year. Another Rust feature which I hope to see implemented before 1.0 releases is rust-lang/rust#65262.
I agree 1.0 should be blocked on const generics. Appears progress is being made. :)
Indeed, and it's exciting! Unfortunately min_const_generics aren't quite powerful enough for our use cases.
Namely we need the ability to use an associated constant of a trait as a const generic parameter. Pretty much every single one of our usages depends on this (i.e. we define sizes using typenum as associated types of a trait, and use those sizes as a parameter for GenericArray).
Here's an experiment I did on the 1.51 beta release which demonstrates the limitation:
https://github.com/RustCrypto/utils/pull/325#issuecomment-791503136
The error message there suggests that both const_generics and const_evaluatable_checked will need to be stabilized before that's possible.
Are there any tools that "assign blame" to dependencies for their compiler resoruce usage?
Are there any tools that "assign blame" to dependencies for their compiler resoruce usage?
Take a look at cargo-bloat and the --time flag.
I just wanna note that the JWK implementation is broken / too strict in what it accepts. JWKs can contain other parameters like kid (Key Identifier), use (one of enc => encryption, sig => signing) and many more. You can find them in the IANA registry. I'm not saying that elliptic-curve should support all these parameters, but it should just ignore them and not fail. Changing this behavior might be a breaking change, so this should be fixed before 1.0
